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

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

 > Right - but you don't need to put the actual data (e.g. the PID and
 > status) through the fd.  I guess it doesn't hurt, but it does make
 > things harder to debug.  Instead, you can save them in memory, and
 > just push a byte through the fd - that will make it show up in select.

OK, if that's simpler.

 > >  > Moving the call to waitpid out of linux-nat.c, and to a target
 > >  > independent file, is a mistake - presumably that's just how you got it
 > >  > to work quickly?  That's related to why it doesn't work for threads.
 > >  > The vital line is "options ^= __WCLONE" in the loop in linux_nat_wait.
 > >  > Without __WCLONE, you'll never see a wait status from a thread; with
 > >  > it you'll never see a wait status from the main program.
 > > 
 > > Perhaps I can use __WALL as a catch all.
 > 
 > There's supposedly some supported kernel versions left where that
 > didn't work.  Why can't you use the same code the existing support
 > uses?

AFAICS the problem is one of timing.  GDB uses the status information in
linux_nat_wait but must detect that the status has changed in the event loop
(gdb_wait_for_event).  However linux_nat_wait makes many calls to waitpid (at
least in the multi-threaded case).  I am/was hoping that, for asynchronous
operation, I only need to replace the first call to waitpid with another one,
which I've called gdb_fetch_event, to read the status information which has
already been waited on.  That's probably a bit naive but I can't see how
I can dart back and forth between gdb_wait_for_event and a single call
to linux_nat_wait.

 > I'm sorry I haven't been able to pitch in and help with this.  I
 > checked it out last week and started looking at it, but I'm buried
 > in work past my eyeballs right now.

I'm just grateful for any help you can give me.

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