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.

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.

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.

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.
http://dlang.org/phobos/core_thread.html#.Fiber.reset

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.
> http://dlang.org/phobos/core_thread.html#.Fiber.reset

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 :(