On Jul 19, 2013, at 12:48 AM, deadalnix <deadalnix@gmail.com> wrote:

> On Thursday, 18 July 2013 at 19:08:25 UTC, Sean Kelly wrote:
>> Functionally, fibers are coroutines.  They have their own stack and execute within the context of the calling thread.  Most languages that scale to thousands or millions of concurrent threads/processes use fibers (often called "green threads" in this context) to pull it off.  The obstacle for D is that global data is thread-local by default, so if we were to use fibers in the back-end to allow the creation of a large number of "threads", fibers would basically need their own TLS to avoid breaking code.  We already do in-library TLS for OSX and so it shouldn't be terribly difficult to use this logic for fibers, but things get tricky once you consider dynamic libraries.  It really should happen at some point though, for std.concurrency to operate at its full potential.
> 
> My take is that we should keep fibers as they are. But change Thread (as the class in the runtime) to be Fibers with FLS and then let the runtime operate system thread and schedule Thread on them.

I think this would most likely happen within std.concurrency, with the context switch occurring on send/receive.

On Jul 18, 2013, at 11:35 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-07-18 21:08, Sean Kelly wrote:
> 
>> We already do in-library TLS for OSX and so it shouldn't be terribly difficult to use this logic for fibers, but things get tricky once you consider dynamic libraries.
> 
> To be able to support dynamic libraries and TLS on Mac OS X we will most likely need to switch to the native implementation of TLS, supported in Mac OS X 10.7 and later. Or we would have to copy/mimic the TLS related code from the dynamic loader into druntime.

And the same for other OSes as well, if we started doing manual TLS for fibers.  Super not fun.  For reference, here's how TLS works on ELF:

http://www.akkadia.org/drepper/tls.pdf

On Monday, 22 July 2013 at 18:24:53 UTC, Sean Kelly wrote:
> I think this would most likely happen within std.concurrency, with the context switch occurring on send/receive.

If so, other libraries won't be able to yield (for instance libraries performing IO).

On Friday, 19 July 2013 at 07:42:26 UTC, deadalnix wrote:
> On Thursday, 18 July 2013 at 17:55:36 UTC, Sean Kelly wrote:
>> On Jul 18, 2013, at 8:28 AM, Matt <MATTCA@sky.com> wrote:
>>
>>> Hi guys,
>>> I know this will have probably been answered before, but does D have a concept similar to Go's channels when it comes to tasks?
>>> 
>>> I believe (according to a few forum posts hinting at it) that such a thing exists for threads, but not for the lightweight tasks provided by std.parallelism. Are there any plans to add such a feature to the library?
>>
>> Not as such.  I'd like to make Fibers each have their own message queue in std.concurrency, but that means making TLS work at the fiber level, which is tricky.
>>
>
> Yes please yes.
>
> Did I said yes yet ?
>
>> I think there is value in the CSP model (ie. channels), but haven't done anything about it in terms of library work.

+1

On Jul 22, 2013, at 11:20 PM, deadalnix <deadalnix@gmail.com> wrote:

> On Monday, 22 July 2013 at 18:24:53 UTC, Sean Kelly wrote:
>> I think this would most likely happen within std.concurrency, with the context switch occurring on send/receive.
> 
> If so, other libraries won't be able to yield (for instance libraries performing IO).

Yes, there would have to be a yield method available for library writers.