kern/19402: Signals 127 and 128 cannot be detected in wait4()
netch at netch.kiev.ua
Mon Apr 30 09:30:18 UTC 2012
The following reply was made to PR kern/19402; it has been noted by GNATS.
From: Valentin Nechayev <netch at netch.kiev.ua>
To: Bruce Evans <brde at optusnet.com.au>
Cc: Jilles Tjoelker <jilles at stack.nl>, bug-followup at FreeBSD.org,
bde at FreeBSD.org
Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4()
Date: Mon, 30 Apr 2012 12:22:54 +0300
Mon, Apr 30, 2012 at 18:24:51, brde wrote about "Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface":
> I think I prefer disallowing signal 128 and not worry about unportable
> programs using it, and not changing anything for signal 127 and not worry
> about the ambiguous wait status from this.
As soon as realtime signals are already kind of feature very limited in
use, and correct program doesn't allocate them in manner linear
dependent on checked descriptor count, I guess it's too improbable to
see a program which uses more than 10-16 realtime signals. Our current
limit 62 is much more.
> However, for mips under Linux, _NSIG is 128,
If they didn't change the wait*() exitstatus ABI under MIPS (and as far
as I see at the code, this ABI is platform independent), Linux have the
same problems with signals 127 and 128 and their usage is incorrect.
I guess it's better to discuss the issue in LKML and wait for Linux reaction.
More information about the freebsd-bugs