Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94374
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.67 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <CAEYWF=7mEsM8wXXpM=d7vLnJRE9a_j7Jns=2P8zr4fOU1WS2eg@mail.gmail.com>
References: <CAEYWF=7mEsM8wXXpM=d7vLnJRE9a_j7Jns=2P8zr4fOU1WS2eg@mail.gmail.com>
Date: Mon, 4 Jul 2016 18:00:02 -0400
Message-ID: <CAEYWF=7oMHYP9W+WvWBg_w1KfbpwqZnwJgZBCnmAxPUEPYEsZw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: David Walker <dave@mudsite.com>
Content-Type: multipart/alternative; boundary=001a11406d2a0ccc570536d6775c
Subject: Re: [RFC] Additional context in pcntl_signal handler (was Re:
 [PHP-DEV] pcntl_signal & sa_siginfo)
From: bishop@php.net (Bishop Bettini)

--001a11406d2a0ccc570536d6775c
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 23, 2016 at 1:18 PM, Bishop Bettini <bishop@php.net> wrote:

> Hi All,
>
> David and I would like to propose a second array argument be added to
> signal handlers registered with pcntl_signal
> <http://php.net/manual/en/function.pcntl-signal.php>. The array passes
> through kernel-provided signal context like the process ID sending the
> signal.
>
> https://wiki.php.net/rfc/additional-context-in-pcntl-signal-handler
>
> RFC links to an implementation. Please try it out and let us know your
> thoughts. This only adds an argument, so no BC break. Maybe too late, but
> it'd be great to get this in 7.1.
>
> On Mon, Jun 13, 2016 at 2:18 PM, David Walker <dave@mudsite.com> wrote:
>
>> Hi All,
>>
>> Long-time lurker, first time questioner here.  I'm currently working on a
>> project wherein I end up forking off many subprocesses, but am trying to
>> keep tabs on the progress of individual forks by having the children send
>> a
>> signal back up to their parent every so often.
>>
>> pcntl_socket, allows me to listen for expected user signals from
>> processes,
>> however, the handler only allows a single argument the signalnumber.  I
>> would like to extend the handler to accept a possible second argument.  If
>> compiled on a system with __siginfo_t it would use SA_SIGINFO when setting
>> up the signal listener, and populate a second argument to the
>> user-callback
>> which could be an array with at leas sa_pid and sa_uid (contents of
>> _kill).
>>
>> So I'd like to source the list to see if this would be something that
>> would
>> be welcomed, or if there would be other ideas on how to get some more info
>> of the signal back to the PHP-side of the pcntl_signal.
>
>
Following a suggestion made earlier, sending notice that voting on this RFC
will open in a few days.

The discussion so far has been recorded in the RFC.

Thoughts appreciated!

--001a11406d2a0ccc570536d6775c--