Concurrency architecture for D2

[Kevin Bealer]

Andrei Alexandrescu Wrote:

> I think we are now in the position of defining a solid set of 
> concurrency primitives for D. This follows many months of mulling over 
> models and options.
> 
> It would be great to open the participation to the design as broadly as 
> possible, but I think it's realistic to say we won't be able to get 
> things done on the newsgroup. When we discuss a topic around here, 
> there's plenty of good ideas but also the inevitable bikeshed 
> discussions, explanations being asked, explanations being given, and 
> other sources of noise. We simply don't have the time to deal with all 
> that - the time is short and we only have one shot at this.
> 
> That's why I'm thinking of creating a mailing list or maybe another 
> group for this. Any ideas on what would be the best approach? I also 
> want to gauge interest from threading experts who'd like to participate. 
> Please advise: (a) whether you would like to participate to the design; 
> (b) keep discussions on the general group; (c) create a separate 
> newsgroup; (d) create a mailing list. The latter would have open enrollment.
> 
> 
> Andrei

I'd love to follow the discussion.  I'm not sure whether I have all that much
expertise for contributing to the "core debate".  It seems like you and Walter
have had a pattern where you discuss things among yourself and post the
occasional "here's our thinking" to a group like this for the rest of us; I'd like
to at least hear about the cool stuff periodically, even if the discussion here
is just chewing the scraps from the real table.

That said, I'll throw out one high level thought on the topic:

As for concurrency itself, my gut reaction is that I'd hope there would be
mutex + thread.  Obviously you want something better, and I look forward
to hearing all the cool stuff about it; but as clunky as we all know mutex +
thread are, it would be good to have them in some form.

One of the downsides of inventing / using a "new thing" is that when all the
existing systems use a particular programming paradigm it becomes hard
to integrate with them if you can't at least emulate that paradigm in a more
or less straightforward way.  If someone is wrapping OpenGL in their D code,
using a C library (just to pick an example, I don't know much OpenGL), it will
be very hard for them to bend OpenGL into an immutable / message passing
approach if it was designed for the land of thread + mutex.

I think that one of the big lessons of what might later be called the "silver
bullet phase" of CompSci, is that there should be a marketplace where the
various paradigms must compete.  If you build a new paradigm for this it is
best if it is a top predator in an ecosystem of ideas, not a new planet with
only a single monoculture.

All paradigms have a place; if a paradigm is used, there is probably a niche
for that approach.  If it exists, it must have value.  Except for bubble-sort.

Kevin