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

Nick Roberts
2006-09-26T23:40:40Z

> 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.