On Fri, 13 Feb 2004 23:31:56 -0500 Rocco Caputo wrote:
+------------------
| Proposal: Registered PIDs.
|
| Currently SIGCHLD is broadcast to every session that registers a CHLD
| signal handler. Quite often, this means every session with child
| processes receives signals for every other one. They all must track
| their children and filter the incoming signals against theirs.
|
| A conversation in IRC reminded me about this issue. I suggested the
| customary pattern for dealing with broadcast SIGCHLD.
|
| One of the parameters is the child PID. You can return unless
| exists $heap->{mine}{$pid}
|
| Philip Gwyn and I had just covered the heavyhanded _signal event,
| which is in the throes of deprecation. It further occurred to me that
| dispatching SIGCHLD to every session with a handler is often useless,
| since most of them don't care one whit about any other session's
| process IDs.
|
| Maybe an optimization would be a Kernel registry mapping child PIDs
| to sessions. After you fork, you can call $kernel->forked($pid) to
| focus that PIDs SIGCHLD on the current session. POE::Wheel::Run
| could do it internally.
|
| Unregistered PIDs would still be broadcast around. And to be fair,
| I guess multiple sessions could register interest in a child PID.
| For whatever that's worth.
|
| This would require a new POE::Kernel method. I wish it could be
| incorporated into something like sig(CHLD => "event"), but re-
| registering the SIGCHLD handler shouldn't be necessary for every new
| process.
+------------------
Is SIGCHLD the only case where additonal context can be used by the
Kernel to decide how to dispatch multicast events to sessions? Is
there a way to implement this feature so that other signals could
take advantage of pushing selection behavior into kernel?
--
