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

Daniel Jacobowitz
2006-09-26T22:24:12Z

On Wed, Sep 27, 2006 at 10:09:38AM +1200, Nick Roberts wrote:
> > Yes, this should work, though it seems cumbersome. When you've got
> > a single thread, you don't need to pass actual data around an fd,
> > just a marker "yes i'm ready now".
>
> I don't quite follow, that's how the event loop works. Even user input
> requires an fd through stdin_event_handler. There is a provision for other
> events but currently only file events are used.

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.

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

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.

--
Daniel Jacobowitz
CodeSourcery