Thread-Multiplexing for D

[Sönke Ludwig]

Am 13.09.2013 12:57, schrieb Dmitry Olshansky:
> 13-Sep-2013 13:57, Sönke Ludwig пишет:
>> Am 12.09.2013 19:55, schrieb Sean Kelly:
>>> On Sep 12, 2013, at 8:34 AM, Bienlein <jeti789 at web.de> wrote:
>>>
>>>> About thread-multiplexing... You find a lot in Google when
>>>> searching for socket multplexing, but not when searching for
>>>> thread-multiplexing. Maybe I coined the term myself (don't know
>>>> any more) when reading the section here:
>>>> http://golang.org/doc/effective_go.html#goroutines
>>>>
>>>> "Goroutines are multiplexed onto multiple OS threads so if one
>>>> should block, such as while waiting for I/O, others continue to
>>>> run. Their design hides many of the complexities of thread
>>>> creation and management."
>>>
>>> The trick in D is that because statics are thread-local by default,
>>> any multiplexed app like this that expects its static data to remain
>>> consistent across calls is likely to fail.  I've mentioned fiber-local
>>> storage here in the past, but it's a tricky problem.  But I think it's
>>> one that we will need to sort out for things like this to work as the
>>> user expects them to.
>>>
>>
>> Until we have something built-in, I've implemented a template based
>> solution for task local storage (same as fiber local storage, but the
>> lifetime is different as fibers get recycled for consecutive tasks):
>>
>> http://vibed.org/api/vibe.core.core/TaskLocal
>
> I do hope O(n) is a typo and it should be O(1).
> Anyhow what n stands here for?
>

n would be the number of variables declared. There is a linear 
initialization cost and in the naive predecessor implementation, an AA 
with Variants was used to store the values, which is why I've mentioned 
efficiency at all.