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

[Paul D. Smith]

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:

  <http://savannah.gnu.org/bugs/?49014>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/