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

Sean Kelly sean at invisibleduck.org
Thu Apr 19 22:08:03 PDT 2012


On Apr 19, 2012, at 9:37 PM, Sean Cavanaugh <WorksOnMyMachine at gmail.com> 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).

I've thought about giving fibers their own TLS so D could have "real" user space threads. It would allow us to make the thread count in apps substantially higher if everything were a fiber and std.concurrency receive, for example, performed a context switch instead of blocking. 


More information about the Digitalmars-d mailing list