• Dzugaru (7/7) May 03 2015 Documentation says "This fiber must be in state TERM." but in the
• Dzugaru (3/3) May 03 2015 Just did another test and it seems its not safe at all. Reusing
• Martin Nowak (4/7) May 03 2015 It won't cleanup the old stack, so it may leak resources. It will
• Martin Nowak (4/12) May 03 2015 Actually the documentation answers your question, please help to
• Dzugaru (12/16) May 03 2015 Created a pull request with your answer added to a Fiber reset

"Dzugaru" <dzugaru gmail.com> writes:

Documentation says "This fiber must be in state TERM." but in the 
core.thread I see In contract only on reset without parameters 
(bug maybe?) and with HOLD condition too:
"assert( m_state == State.TERM || m_state == State.HOLD );"

Does that mean its ok to reset the fiber if I'm not using things 
like scope(exit)? I don't like adding "if(fibIsDestroyed) 
return;" snippet after each Fiber.delay() - its error-prone.

"Dzugaru" <dzugaru gmail.com> writes:

Just did another test and it seems its not safe at all. Reusing 
the fibers with reset without properly exiting the function leads 
to eventual stack overflow.

"Martin Nowak" <code dawg.eu> writes:

On Sunday, 3 May 2015 at 12:42:23 UTC, Dzugaru wrote:
 Just did another test and it seems its not safe at all. Reusing 
 the fibers with reset without properly exiting the function 
 leads to eventual stack overflow.

It won't cleanup the old stack, so it may leak resources. It will 
properly reset the stack though, so the fiber should behave like 
a new one.

"Martin Nowak" <code dawg.eu> writes:

On Sunday, 3 May 2015 at 12:33:36 UTC, Dzugaru wrote:
 Documentation says "This fiber must be in state TERM." but in 
 the core.thread I see In contract only on reset without 
 parameters (bug maybe?) and with HOLD condition too:
 "assert( m_state == State.TERM || m_state == State.HOLD );"

 Does that mean its ok to reset the fiber if I'm not using 
 things like scope(exit)? I don't like adding 
 "if(fibIsDestroyed) return;" snippet after each Fiber.delay() - 
 its error-prone.

Actually the documentation answers your question, please help to 
improve it if you don't find it clear enough.

"Dzugaru" <dzugaru gmail.com> writes:

On Sunday, 3 May 2015 at 14:36:04 UTC, Martin Nowak wrote:
 On Sunday, 3 May 2015 at 12:33:36 UTC, Dzugaru wrote:

 Actually the documentation answers your question, please help 
 to improve it if you don't find it clear enough.


Created a pull request with your answer added to a Fiber reset 
method description. In my opinion it should be either disallowed 
to reset the fiber in a HOLD state or clearly documented that 
stack wont be cleaned. I'm dreaded to think about random crashes 
in my app some hours after launch because of fiber reusing. Also, 
I'm not familiar with contract programming, but shouldn't the 
"in" "body" clause be included in all overloads of a reset, not 
just first?

Now I'm thinking about how to do unfinished fiber reusing 
properly. Adding "if(!isFibTerminated) return;" after every 
"Fiber.yield()" is not good :(