[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #49014] Zombies in parallel builds with pselect code

From: Paul D. Smith
Subject: [bug #49014] Zombies in parallel builds with pselect code
Date: Wed, 14 Sep 2016 13:55:29 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

Follow-up Comment #6, bug #49014 (project make):

It can't be implemented in userland.  What pselect() does is unblock the
signal, call select, then have the signal blocked again on return.  The point
of using pselect() is that the signal unblock/block must be atomic with the
select() system call.  Otherwise between the instant you unblock the signal
and invoke select(), the signal could arrive and you miss it.  Ditto for after
select() returns and before the signal is blocked again.  There's no way to
avoid that from userland.  The Linux man page for pselect has a good
explanation, as does this LWN article: https://lwn.net/Articles/176911/

I looked at the NetBSD man page but it didn't say clearly one way or the other
whether it used a system call or not.  If you've checked and verified it uses
a system call that's good.

I have to say I still don't see what the bug could be.  Stripping out all the
ifdefs etc. the handling of SIGCHLD is very simple when HAVE_PSELECT is set so
it's hard to know what might be wrong.  I think we may have to involve the
NetBSD devs to talk about how pselect() works there.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]