Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89803
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain dennis.birkholz.biz does not designate 144.76.185.252 as permitted sender)
To: 'PHP Internals' <internals@lists.php.net>
Message-ID: <566B55B5.1070709@dennis.birkholz.biz>
Date: Sat, 12 Dec 2015 00:01:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: PULL request: allow signals up to SIGRTMAX
From: php@dennis.birkholz.biz (Dennis Birkholz)

Hi together,

for some time now I have a pull request open
(https://github.com/php/php-src/pull/1457) where I want to introduce the
two constants SIGRTMIN and SIGRTMAX and allow pcntl_signal() to register
handlers for "real-time signals" (from SIGRTMIN to SIGRTMAX).

From the signal manpage:
> Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined purposes.

This allows cli applications/long running processes to communicate via
signals without assigning unexpected meaning to the well-known lower
(<SIGRTMIN) signals.

From what I see in the source code, all other functions related to
signals already handle signals in such a generic way that using
real-time signals is possible without a problem except you can not
safely know the actual values of SIGRTMIN and SIGRTMAX and you can not
register a handler for them with pcntl_signal().
Is there a need to create an RFC for this change? Or can someone review
it and maybe apply it?

Thanks,
Dennis