Asynchronicity in D

[Sean Kelly]

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.