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.