module initialization order issue

[Peter Alexander]

On Sunday, 3 March 2013 at 16:07:58 UTC, Benjamin Thaut wrote:
> Am 03.03.2013 16:29, schrieb Peter Alexander:
>> On Sunday, 3 March 2013 at 12:01:10 UTC, Benjamin Thaut wrote:
>>> Is this a bug, or is this intended beahvior? I always 
>>> believed that
>>> with all the dependency detenction that is done such 
>>> situation should
>>> not happen.
>>
>> It's intended behaviour.
>>
>> Remember that shared static this() is only run once for the 
>> whole
>> program, whereas static this() is run per thread. Using 
>> per-thread data
>> inside something that's run per-program doesn't make a whole 
>> lot of sense.
>
> Well this is of course a reduced version of a real issue I'm 
> having. I have thread local stack allocators. Each thread has 
> its own stack allocator and certain parts of my code use these. 
> What happened now is, that I inserted a call into a shared 
> static module constructor which calls a function which in turn 
> uses a thread local stack allocator. The problem is, that the 
> thread local stack allocator module is not fully initialized at 
> that point.
>
> But I think I can work around it by adding a shared static 
> constructor and initialize the thread local stack alloactor for 
> the main thread there.

It's a tricky situation. There are bad situations no matter which 
order things happen.

At least the order is defined. Having this kind of thing break in 
non-deterministic ways would be a lot less fun.