--- Comment #11 from Witold Baryluk <bary...@smp.if.uj.edu.pl> 2012-02-15
08:09:20 PST ---
(In reply to comment #10)
> >Hm... that's tricky. The fiber implementation needs to hold a reference to
> >fiber on its stack for context switching, and that's the reference that is
> >keeping the fiber alive. I'll play with the stack pointers a bit and see if
> >things work if I exclude that reference from the GC scan.
> It's simple to fix I think. Don't add the fiber context to the global context
> list but GCscan all nested contexts instead. Now you only need to push/pop a
> reference to the Fiber object for call/yield.
Well I agree.
My reasoning is - if fiber is not currently executed and is not referenced by
anything from live set (all live threads, and all executing fibers, and all
threads and fibers referenced by them recursively), then there is no way to
resume execution of fiber (or terminate it manually, or change it), and it's GC
job to terminate and delete it.
> It's like swapping ownership. When the fiber is halted the Fiber object owns
> it's stack, when the fiber is being executed the stack owns the Fiber object.
It will probably introduce small additional overhead to Fiber context switching
and execution, but should not be much. I will be happy to test any fix which
resolves this problem.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------