Re: Merge of nickrob-async-20060513 to mainline?

[Nick Roberts <nickrob@snap.net.nz>]

 > > Instead of GDB waiting for the enferior to stop directly, it creates a
 > > signal thread to do that.  This means that the main thread can continue to
 > > process the event loop.  When the inferior does stop, the signal thread
 > > writes to a file which GDB detects through handle_file_event in the event
 > > loop. It then calls inferior_event_handler.
 > 
 > OK, this is easily mimicable without threads, at least on GNU/Linux.

Easy being in the eye of the beholder!

 > On Cygwin/Windows I imagine we'd want to use threads, but the tradeoffs
 > there are somewhat different :-)

As there are platform specific changes e.g to linux_nat_attach, linux_nat_wait,
i386_linux_resume etc, I guess they need to be added on a case by case basis.
Presumably this could be done incrementally i.e we could merge asynchronous
operation on GNU/Linux into GDB without waiting for it to work on
Cygwin/Windows.

 > > The manpage just says:
 > > 
 > >        WNOHANG
 > >               return immediately if no child has exited.
 > > 
 > > but what value does it return with?  Does GDB ignore SIGCHLD events so it
 > > can detect state changes through wait?
 > 
 > If that's all it says I recommend a better man page :-)
 > 
 >        waitpid(): on success, returns the process ID of the child whose
 >        state has changed; on error, -1 is returned; if WNOHANG was
 >        specified and no child(ren) specified by pid has yet changed
 >        state, then 0 is returned.

Doh!

 > Different ports of GDB treat SIGCHLD differently.  linux-nat.c, for
 > instance, blocks it so that it can use sigsuspend.  Instead, we would
 > have to register handlers for sigchld events somehow (probably using
 > the same infrastructure used for SIGINT to quit operations).
 > 
 > I can work on this, though not right away.

Thanks.

-- 
Nick                                           http://www.inet.net.nz/~nickrob