Threads and static initialization.

[Robert Jacques]

On Sat, 18 Dec 2010 15:04:38 -0700, Michel Fortin  
<michel.fortin at michelf.com> wrote:
> On 2010-12-18 15:57:50 -0500, "Robert Jacques" <sandford at jhu.edu> said:
>
>> On Sat, 18 Dec 2010 03:27:22 -0700, Pelle Månsson   
>> <pelle.mansson at gmail.com> wrote:
>>
>>> On 12/18/2010 10:00 AM, Jonathan M Davis wrote:
>>>> The problem is that the OP wants the static constructors to be  
>>>> skipped.  If
>>>> they're skipped, anything and everything which could be affected by   
>>>> that can't be
>>>> used. That pretty much means not using TLS, since the compiler isn't   
>>>> going to be
>>>> able to track down which variables in TLS will or won't be affected  
>>>> by  it. So,
>>>> you're stuck using shared memory only. _That_ is where the problem   
>>>> comes in.
>>>  Exactly, not using TLS. You can still use the heap, as it is not  
>>> thread  local. Meaning you can create non-shared anything all you  
>>> like, as long  as you're not using TLS.
>>  Except that the 'heap' internally uses TLS. The GC does need and use  
>> TLS.
>
> Using D's TLS for the GC is an implementation choice, not a requirement.  
> If someone wants to optimize 'spawn' for pure functions by skipping D's  
> TLS initialization, he can make the GC and the array appending cache  
> work with that.
>

Not really, as _every_ modern GC requires TLS. And we're talking about a  
performance optimization here: not supporting modern GCs in order to  
remove TLS initialization would be a penny-wise pound foolish move.  
Besides, 'mini' threads shouldn't be created using OS threads; that's what  
thread-pools, fibers and tasks are for.