This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Merge of nickrob-async-20060513 to mainline?
> > 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