Hi,
To keep maximum compatibility and eliminate unnecessary additional overhead, I would keep pcntl_signal() unchanged, but add pcntl_sigaction() with the ability to specify the need for the second argument (In the same way as POSIX does). Joe, Davey, when we stop targeting new RFCs for 7.1? Thanks. Dmitry. ________________________________ From: bishop.bett...@gmail.com <bishop.bett...@gmail.com> on behalf of Bishop Bettini <bis...@php.net> Sent: Thursday, June 23, 2016 8:18:58 PM To: PHP internals Cc: David Walker Subject: [PHP-DEV] [RFC] Additional context in pcntl_signal handler (was Re: [PHP-DEV] pcntl_signal & sa_siginfo) 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. Thanks! bishop On Mon, Jun 13, 2016 at 2:18 PM, David Walker <d...@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. > > -- > Dave >
