Taking Chris' question further... why not implement wait queues (I'm
thinking along the lines of NT). Any session could declare it's interest
on a waitable object... and anyone with a reference to that object could
call wakeup on it. SIGCHLD handling is therefore just a special
case of this - you have a handle on the process, register you want to wait
on it. When the pid dies, the object referring to that PID could get a
wakeup event. If the waitqueue is empty, the process vaporises in a puff
of logic. Else the sessions that declared interest get woken.
Nick.
On Fri, 13 Feb 2004, Chris Fedde wrote:
> 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?
>
> --
>
