Thanks, flw and Nick. https://github.com/rcaputo/poe/commit/d65590f5c0c065d49a342e94e48b8167f4f5c633 should resolve it.
That change will defer GC until the next sweep. There could be a potential problem if the sweep doesn't happen, but I don't know how that might occur. -- Rocco Caputo <rcap...@pobox.com> On Apr 8, 2011, at 04:10, Nick Perez wrote: > I do believe this is indeed a bug, but not in POE::Session. It seems > the GC semantics have changed somewhat and call() specifically invokes > a GC sweep in the cases where a return value is expected from an event. > > I think this behavior is wrong (and I may have been the ultimate reason > this behavior exists at all [GC after call()], some long long time > ago sadly). For intra-session call()s, GC should not be called. > Effectively, the $kr_active_session is $session, meaning that we are > inside an event in $session that is current executing. GC should be > reserved for when that source event finishes, not in the middle of it. > So what I think is happening is this: his call invokes a GC sweep a > couple of times until it depletes the event_count at which point the GC > sweep will collect the session. But since kr_active_session is still > around, delay() has no problem enqueuing an event against it. Then when > the zombie session's state is invoked, Kernel happily dispatches even > when it can no longer resolve the session (for source_session), since > the reference is still valid. ASSERT_DEFAULT catches this, by the way. > > Recommendation: remove the _data_ses_gc_sweep() calls in call(). > > For what it is worth the tests seem to run fine on my machine with > these calls removed from call(). > > > On Fri, 8 Apr 2011 11:57:18 +0800 > flw <su2ad...@gmail.com> wrote: > >> Sorry for my poor english, let me show it just by code. [test case removed]
