Re: Concurrency, again

[Ken Raeburn]

> On Oct 20, 2016, at 03:12, Herring, Davis <address@hidden> wrote:
> 
>> we do that by calling waitpid() but then the kernel discards the child
>> process’s status info, so the "correct" thread can no longer respond
>> to the signal by making another waitpid() call to collect the status
>> info.  We’d have to save the info the first time we call waitpid().
>> But doing it from within the signal handler could be tricky, because
>> in that context we’re limited to async-signal-safe functions, and
>> helpful routines like malloc() and pthread_mutex_lock() aren’t on the
>> list.
> 
> waitid() supports the WNOWAIT flag that peeks at the child information 
> without destroying it: 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/waitid.html

Ah, yes, thanks!  I wasn’t aware of that one.  I think the last time I had to 
deal with the wait* interfaces in portable code was back before POSIX support 
could be assumed…. :-)

Still, sending signals back and forth between threads so each can wait on its 
own child processes (and also somehow dealing with the ones not bound to any 
specific thread) seems messy compared to the waitpid daemon thread approach of 
NSPR.

Ken