Robert Jacques wrote:
On Tue, 13 Oct 2009 11:19:30 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
