http://d.puremagic.com/issues/show_bug.cgi?id=3523
--- Comment #11 from Witold Baryluk <[email protected]> 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 > >the > >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: -------
