Date: Mon, 30 Apr 2012 09:30:17 GMT From: Valentin Nechayev <netch@netch.kiev.ua> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface Message-ID: <201204300930.q3U9UHiK060230@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/19402; it has been noted by GNATS.
From: Valentin Nechayev <netch@netch.kiev.ua>
To: Bruce Evans <brde@optusnet.com.au>
Cc: Jilles Tjoelker <jilles@stack.nl>, bug-followup@FreeBSD.org,
bde@FreeBSD.org
Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4()
interface
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.
-netch-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204300930.q3U9UHiK060230>