Concurrency architecture for D2

retard re at tard.com.invalid
Mon Dec 28 11:32:29 PST 2009


Mon, 28 Dec 2009 10:20:53 -0600, Andrei Alexandrescu wrote:

> Michel Fortin wrote:
>> On 2009-12-27 15:32:52 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>> 
>>> 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.
>> 
>> I think it should be as open as possible. If done in a separate smaller
>> group, it may be a good idea to post reports to the general newsgroup
>> more or less regularly so that those who cannot participate in the
>> detailed discussions have an idea of where it's going, and also to get
>> more general input.
> 
> That's obviously the best way to go, but there are a couple of
> circumstances that make that more difficult.
> 
> 1. Chapter drafts will be the basis for discussion, but understandably
> the publisher does not allow me to freely distribute them.
> 
> 2. Time. There are regulars on this group that have a "when in doubt,
> make them sweat" policy. I think it's a very good and gainful attitude
> for everyone involved, and I generally enjoy discussing this or that
> idea because it helps me and others gain a better understanding, but
> this time there won't be much time for discussions of the form:
> 
> a) Poster: "Subtle issue X sounds like a bad idea. I don't agree with
> it."
> 
> b) <Long argumentation back and forth.>
> 
> c) Poster: "I stay unconvinced." or "That makes sense."
> 
> There will be very little time for anything like this, particularly if
> explaining X requires a fair amount of background building.
> 
> Building a shared vision is very difficult among only a small group of
> people, and doing so for a larger group will be an enormous drag. I feel
> very lucky that Walter and I share views most of the time (except, of
> course, when he's wrong :o)).

I think a shared vision is easier to achieve in a small group. If the 
group size is 1, you only need to convince yourself, if 2, you have only 
one other person who needs to agree and so forth. In groups like c++ 
standards committee every player in the software industry wants to be 
heard. That's why it's not gonna be c++0x anymore, maybe c++1x (c++0x0a) 
or c++2x.

I don't like how in D community new features are added. We often first 
get a binary dmd release containing the new feature, after that some 
obscure half-official explanation about the corner cases that will be 
fixed in the next release. Only after that Walter might answer 'Yes.' to 
some well laid questions and finally after 2-3 years a very terse 
informal text is added to the specification.

What kind of experts are you exactly seeking now? Guys who build massive 
and scalable native/green thread pools to serve http requests? Guys who 
compute weather forecasts with 10.000 node MPI setups? Is it going to be 
a multi-threaded, multi-core, or multi-computer architecture?



More information about the Digitalmars-d mailing list