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

[Jameson Ernst]

On Friday, 20 April 2012 at 04:37:32 UTC, Sean Cavanaugh wrote:
> On 4/19/2012 10:00 PM, Jameson Ernst wrote:
>> On Thursday, 19 April 2012 at 00:07:45 UTC, Sean Kelly wrote:
>>> On Apr 18, 2012, at 4:06 PM, Andrew Lauritzen wrote:
>>>
>>>> I'm still interested in if anyone has any suggested 
>>>> workarounds or
>>>> experience using Win32 fibers in D2 as well.
>>>
>>> The x32 Windows code should be pretty well tested. If this is 
>>> using
>>> the x64 code though, that's all quite new. I'll give this a 
>>> try when I
>>> find some time, but can't suggest a workaround offhand. It 
>>> almost
>>> sounds alignment-related, which could be tricky.
>>
>> Been following D for a while now, and fibers right in the std 
>> lib are a
>> huge draw for me. I'm not an expert on them, but on the topic 
>> of x64
>> fibers, I have some exposure to them trying to contribute x64 
>> windows
>> support to bsnes, which uses its own home-grown 
>> fiber/coroutine system.
>>
>> Out of curiosity I took a look at the D fiber context code, 
>> and noticed
>> that the x64 windows version doesn't seem to save the XMM6-15 
>> registers
>> (unless I missed it), which is something I forgot to do also. 
>> MSDN
>> indicates that they are nonvolatile, which could potentially 
>> cause
>> problems for FP heavy code on x64 windows.
>>
>> Not sure if I should file a bug for this, as I haven't tried 
>> an x64
>> windows fiber in D yet to make sure it's actually a problem 
>> first.
>
> Fibers seem like a last resort to me.  They are fairly 
> difficult to make bulletproof due to the thread local storage 
> issues and a few other problems with context switches.  Win7 
> scheduling and management of real threads is a lot better than 
> in previous versions, and in x64 mode there is also user mode 
> scheduling (UMS) system and the library built on top of it 
> (ConcRT), which gets you almost all of the benefits of fibers 
> but you get to use 'real' threads, plus the added bonus of 
> being able to switch to another thread when you stall on a page 
> fault or block on a kernel object (something fiber's can't do).

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).

This capability makes C# very compelling for game development, 
and we use it extensively at work on both the client and server 
side. D could really eat its lunch by making fibers first-class 
and portable.