This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Merge of nickrob-async-20060513 to mainline?
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 6 Oct 2006 15:10:37 +1300
- Subject: Re: Merge of nickrob-async-20060513 to mainline?
- References: <17652.63229.637451.185345@kahikatea.snap.net.nz> <20060830023335.GA6377@nevyn.them.org> <17653.930.196634.143646@kahikatea.snap.net.nz> <20060830040113.GA8257@nevyn.them.org> <17654.994.815362.897653@kahikatea.snap.net.nz> <20060830214257.GA5397@nevyn.them.org> <17688.59135.24869.397517@kahikatea.snap.net.nz> <20060926123757.GA9879@nevyn.them.org> <17701.43098.583849.540224@kahikatea.snap.net.nz> <20061006012633.GA20001@nevyn.them.org>
> So when you want to wait, you make sure such a signal handler is
> installed for SIGCHLD, unblock SIGCHLD, and call select on a set of fds
> that includes the one written to by the signal handler. If you get a
> byte on that fd, you know there's a child ready to be waited for. When
> you're done waiting, you re-block the signal. It's possible to get
> spurious wakeups this way (for instance if a signal is received between
> the return of select and the re-blocking), but with a little care
> everything works out OK.
>
> This is actually pretty similar to the way you do it with threads.
>
> Does that make sense?
Yes I think so. I don't quite follow the explanation of pselect in the manpage
but I think you're saying that the signal handler for SIGCHLD will run even
when GDB is already in select, and can get GDB's attention by writing to a
pipe with a file descriptor that select is watching.
--
Nick http://www.inet.net.nz/~nickrob