From owner-freebsd-bugs@FreeBSD.ORG Mon Apr 30 09:30:18 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12FF11065670 for ; Mon, 30 Apr 2012 09:30:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F0F5E8FC08 for ; Mon, 30 Apr 2012 09:30:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3U9UHe3060233 for ; Mon, 30 Apr 2012 09:30:17 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3U9UHiK060230; Mon, 30 Apr 2012 09:30:17 GMT (envelope-from gnats) Date: Mon, 30 Apr 2012 09:30:17 GMT Message-Id: <201204300930.q3U9UHiK060230@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Valentin Nechayev Cc: Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Valentin Nechayev List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 09:30:18 -0000 The following reply was made to PR kern/19402; it has been noted by GNATS. From: Valentin Nechayev To: Bruce Evans Cc: Jilles Tjoelker , 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-