> Good morning. > > I have committed a change to cvs that alters the way poe dispatches > signal events. The change shouldn't affect most programs, but it's > fundamental enough that people should test it early. I'd like to > shake out any bugs before it's released to the general public. > > Instructions for fetching poe are at the bottom of > http://poe.perl.org/?Where_to_Get_POE > > Old signal dispatching. > > Signals were dispatched depth-first through sessions' parent/child > hierarchy. In other words, child sessions would receive signal events > before their parents. > > Some signals will stop sessions if they aren't handled. In the past, > this meant that signals might stop components while leaving the rest > of the program intact. > > New signal dispatching. > > The new dispatch algorithm defers session destruction until a signal > has been fully dispatched. Every signaled session now has a chance to > handle a signal before any session is stopped. If the signal goes > unhandled, then all the sessions are stopped together. Otherwise, all > the signaled sessions survive. > > The signal dispatch order has changed, too. Sessions that have used > $kernel->sig() to watch for signals will receive their events before > the others. This may cause problems for programs that depend on the > order in which signal events are dispatched. > > More about signal reforms. > > The three-pass signal dispatch is the first of a series of signal > fixes. A full summary of the changes has been on display in the > Planning Department for four of your Earth years. You may read it at > http://poe.perl.org/?POE_RFCs/Signal_Reforms > > If you have comments or concerns, please share them. >
My concern should already be known, I don't think POE should listen to signals unless atleast one session is interested in it. I still have that 100% loop when POE catches signals and makes libdb confused, or maybe libdb makes POE confused... Arthur
