http://d.puremagic.com/issues/show_bug.cgi?id=3523



--- Comment #10 from dawg@dawgfoto.de 2012-02-15 04:15:06 PST ---
>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.
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3523



--- Comment #11 from Witold Baryluk <baryluk@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 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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3523


Alex Rønne Petersen <alex@lycus.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alex@lycus.org


--- Comment #12 from Alex Rønne Petersen <alex@lycus.org> 2012-10-10 03:54:02 CEST ---
What is the status of this today?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3523



--- Comment #13 from dawg@dawgfoto.de 2012-10-16 18:06:40 PDT ---
>When the fiber is halted the Fiber object owns it's stack

This doesn't work out with our current GC mechanisms and the required stack scans.

The other solution I can think of is to keep the inner stack free of any references to the enclosing fiber. This would imply that all Fiber bookkeeping must be done using asm or on the outer stack to fully avoid pointer leakage.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------