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.
