Revamped concurrency API

[Jeremie Pelletier]

Robert Jacques wrote:
> On Tue, 13 Oct 2009 11:19:30 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
>> MIURA Masahiro wrote:
>>> Jeremie Pelletier wrote:
>>>> I also don't believe one model is "ruling them all".
>>>
>>> Let me clarity this, just in case I have caused an unnecessary
>>> confusion:  I think Sean's Erlang-like API is meant to coexist
>>> with the current core.thread, and that you can use one or both
>>> of them to build higher-level concurrency models.
>>>
>>> I think it's nice to have core.thread *and* message-passing API
>>> in Phobos.  Thread alone is too primitive for daily use, but
>>> we don't want to have too many concurrency models.
>>
>> Absolutely! I agree. We need to attack the beast with everything we 
>> have.   
>>
>> Andrei
> 
> I'd recommend reading Bartosz's blog on thread objects vs spawn 
> (http://bartoszmilewski.wordpress.com/2009/09/01/spawning-a-thread-the-d-way/). 
> It makes a really good case for why thread objects should never be 
> sub-classed and therefore should be a private, hidden implementation 
> detail and not a public API.

Threads should NOT be private, I don't mind making them final classes 
but some programs may not require, or some programmers may not want, the 
high level constructs.

If you put the thread construct in core.thread and the concurrent 
implementations in std.concurrent you still need the std api to access 
the core threads. But threads being a core module makes it a "here it is 
should you want it, but check these standard modules first" kind of module.

Threads being public also allow any programmer to build custom 
concurrent models if they're not in the library.

Jeremie