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

[Daniel Jacobowitz <drow@false.org>]

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