Windows: Throwing Exceptions from Fibers in D2.059: Access Violation

[Sean Kelly]

On Apr 20, 2012, at 10:21 AM, Andrew Lauritzen wrote:

>> To be precise, fibers in and of themselves aren't exacty what I want, but are the best means to getting it that I've seen so far. They enable efficient implementation of coroutines, which many languages either cannot express at all, or can only express very poorly by using the sledgehammer of a full-on kernel thread to get it. A call stack is a very useful way to group logic, and being forced to go outside the language and ask the OS for another one is a shame.
>> 
>> Game logic is an area where this technique REALLY shines. Case in point: Unity3D. The entire engine is built around C#'s iterator method facility to implement coroutines to control entity logic. Hundreds or even thousands of them can be active with very little overhead compared to a full thread context switch. Unfortunately, they're hamstrung by not being a true coroutine (you can only yield from the top frame).
>> 
> Right, exactly the above! Fibers are totally uninteresting as a "lighter thread" or unit of scheduling for the reasons that you note, but coroutines are just a better way to write a lot of code. This is basically the entire premise for the Go programming language, so it's worth taking a peek at that if you haven't already.

Okay, here's the talk:

http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html

I've been digging around and just found Mikola's coroutine implementation on my hard drive.  It would have to be updated, but I do have the code.  Maybe this should be added to Druntime.


>> Stack overflow?  Give the fiber a larger stack when you create it. The default is really rather small.
> 
> I'm fairly certain that it's not a "real" stack overflow... the program continues to operate normally unless the debugger is stepping through and it only happens when an exception is thrown. And it happens pretty much always when an exception is thrown, you just won't see it unless you have a debugger attached to see the output. So like I said, it is somewhat worrisome, but the program seems to be running properly despite it, so it may be a red herring.

It could be a "real" stack overflow.  I can't remember the details, but this happened once before when the default stack size was 4k.  Something about how exceptions are thrown right now has pretty considerable stack requirements on Windows--maybe the stack trace generation?  Anyway, that's why the default stack size for fibers is currently 8k IIRC.