as long as the child's process id remains available in the current place you won't break existing code like PoCo::Child so no objections here :)
-----Original Message----- From: Rocco Caputo [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 8:32 PM To: [EMAIL PROTECTED] Subject: Proposal: Registered PIDs 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. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
