Asynchronicity in D

[dsimcha]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> On Mar 31, 2011, at 4:03 PM, dsimcha wrote:
> > == Quote from Sean Kelly (sean at invisibleduck.org)'s article
> >> On Mar 31, 2011, at 11:48 AM, dsimcha wrote:
> >>> == Quote from Andrej Mitrovic (andrej.mitrovich at gmail.com)'s
> >> article
> >>>> Are fibers really better/faster than threads? I've heard rumors
> that
> >>>> they perform exactly the same, and that there's no benefit of using
> >>>> fibers over threads. Is that true?
> >>>
> >>> Here are some key differences between fibers (as currently
> implemented
> >> in
> >>> core.thread; I have no idea how this applies to the general case in
> >> other
> >>> languages) and threads:
> >>>
> >>> 1.  Fibers can't be used to implement parallelism.  If you have N >
> 1
> >> fibers
> >>> running on one hardware thread, your code will only use a single
> core.
> >> It bears mentioning that this has interesting implications for the
> >> default thread-local storage of statics.  All fibers running on a
> thread
> >> will currently share the thread's static data.  This could be worked
> >> around by doing TLS manually at the fiber level, but it's a
> non-trivial
> >> change.
> >
> > Let's assume for the sake of argument that we are otherwise ready to
> make said
> > change.  What would the performance implications of this be for
> programs using TLS
> > heavily but not using fibers?  My gut feeling is that, if this has
> considerable
> > performance implications for non-fiber-using programs, it should be
> left alone
> > long-term, or fiber-local storage should be added as a separate
> entity.
> It's more an issue of creating an understandable programming model.  If
> someone is using statics, the result should be the same regardless of
> whether the code gets a dedicated thread or is multiplexed with other
> code on one thread.  ie. fibers are ideally an implementation detail.

Yes, but what would be the likely performance cost of doing so?