This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Rework/simplify linux native asynchronous support.


Hi Tom, thanks for taking a look, and sorry in the delay
in getting back to this.

On Thursday 16 April 2009 19:33:05, Tom Tromey wrote:

> I seem to remember that there was a reason not to use the async event
> handler code from event-loop.c.  It would be nice if there were a
> comment somewhere in the file explaining why the pipe approach is used
> instead.

Because a SIGCHLD signal can arrive at any time.  If the signal
arrives just before we block in select/poll, and we didn't use
a waitable file, we'd handle the signal and then we'd block
in select/poll.  Using a waitable file as event source (like
a pipe), is one portable way to solve that (google for
self-pipe trick).  pselect/ppoll would be another fancy way,
but that is unuseable, as you can read on the BUGS section of
the pselect man page.  The async event handler code is only
useable when you're sure to only mark the event source while
not close to the event loop code, e.g., like the remote.c case,
where it is only marked in "main", non-signal code, as a way
of marking something to be done later when you get
back to the event loop.

> I also didn't understand the call to async_file_flush in
> async_file_mark.

It's not strictly needed, but, since we don't know how many stops
happened when we get a SIGCHLD signal (the kernel can coalesce
more than one), it doesn't matter how many bytes there are in the
pipe.  This call just flushes the pipe just before we know we're
going to leave with a single byte there.

I have an updated patch that fixes a couple of races (there are a couple
of places that we need to block SIGCHLD that I removed overeagerly),
that I'll need to send along.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]