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

[Jameson Ernst]

On Friday, 20 April 2012 at 18:09:37 UTC, Sean Kelly wrote:
> On Apr 20, 2012, at 10:59 AM, Andrew Lauritzen wrote:
>
>> On Friday, 20 April 2012 at 17:49:52 UTC, Sean Kelly wrote:
>>> There wouldn't me much of a performance hit, mostly an 
>>> additional allocation and a bitcopy when creating a Fiber.  
>>> It's more that making this work on platforms with built-in 
>>> TLS could be quite tricky.
>> Note that this would somewhat sabotage their usefulness as 
>> coroutines, depending on how it was implemented. That's not to 
>> say the idea isn't good (but I'd frame it more like "tasks"; 
>> see Thread Building Blocks or similar), but fibers/coroutines 
>> as they stand now are useful so I'd hate to see that 
>> capability lost.
>
> Ah, coroutines would actually want to share TLS with the 
> executing thread?  That's good to know.

Yeah, I think there's a subtlety at play here, but it's an 
important one. In most languages and environments, a thread of 
execution and a call stack are conflated into a single entity. I 
think what Andrew and I are driving at is that we'd like them to 
be orthogonal concepts.

A "thread" is merely a lane of execution, and that lane can play 
host to any call-stack "fiber" context we'd like it to. For this 
reason, it's important that fibers not be bound to the thread 
that initially created them. Mono implemented a continuation 
system, but the stack context is tied to the thread that spawned 
it, which is frustrating and prevents efficient task pooling.