std.concurrency and fibers

[Dmitry Olshansky]

On 04-Oct-12 16:48, Timon Gehr wrote:
> On 10/04/2012 02:22 PM, Alex Rønne Petersen wrote:
>> On 04-10-2012 14:11, Timon Gehr wrote:
[snip]
>>
>> I think that no matter what we do, we have to simply say "don't do that"
>> to thread-local state (it would break in distributed scenarios too, for
>> instance).
>>
>> Instead, I think we should do what the Rust folks did: Use *task*-local
>> state and leave it up to std.concurrency to figure out how to deal with
>> it. It won't be as 'seamless' as TLS variables in D of course, but I
>> think it's good enough in practice.
>>
>
> If it is not seamless, we have failed. IMO the runtime should expose an
> interface for allocating TLS, switching between TLS instances and
> destroying TLS.
>
Agreed.

> What about the stack? Allocating a fixed-size stack per task is costly
> and Walter opposes dynamic stack growth.

Allocating a fixed-size stack is costly only in terms of virtual address 
space. Then running out of address space is of concern on 32-bits only. 
On 64 bits you may as well allocate 1 Gb per task it will only get 
reserved if it's used.

-- 
Dmitry Olshansky