Revamped concurrency API

[Michel Fortin]

On 2009-10-13 18:26:04 -0400, Bartosz Milewski 
<bartosz-nospam at relisoft.com> said:

> I didn't so much "decline to contribute" as hit a wall. I'm a bit of a 
> perfectionist and it's hard for me to subscribe to the "good enough" 
> philosophy (as long as it's better that C++, it's fine for D). My 
> impression is that, as the release of D2 and the publication of 
> Andrei's book are nearing, this attitude is gaining ground. I try to 
> fight this attitude but it's an uphill battle. Or, as Andrei puts it, I 
> start whining and give up ;-).

I don't like that attitude either. I'd rather remove completely an 
unfinished feature than leave it there half-done. If the main feature 
of D2 is a new concurrency model, then leaving things in the state they 
are now isn't going to impress much.


> The semantics of "shared." I can live with postponing the 
> implementation of the race-free type system, but not with the compiler 
> inserting barriers around all shared reads and writes, even inside 
> synchronized sections.

I hadn't thought about that, but it's somewhat ridiculous. On my part 
I'm more preoccupied by the absence of lent semantics as it goes much 
deeper than concurrency: you need it to implement proper invariant 
constructors and unique references.


> The C++-derived template metaprogramming mess. Especially when C++0x 
> provides better support for variadic templates than D (see my upcoming 
> blog). I fought successfully for non-functional approach to string 
> mixins. The same is needed for more general templates. In my opinion, 
> there should not be any part of the language that is understandable 
> only by seasoned library writers.

I'm quite eager to read about that.


> The "better than Java" aspect of D ignores the latest development in 
> Java. In particular the work on non-null pointers and the use of 
> annotations for type-system extensions. Annotations are being added to 
> D as we speak because it finally became obvious that no amount of 
> cleverness can make object properties work without additional syntax. 
> So the patching begins, without a clear vision of the role of 
> annotation in future D.

I'm not even sure what convinced Walter to put annotations in and what 
they're supposed to be capable of. I hope it's not just a new way to 
create keywords without them really being keywords.


> As far as my thread work went, I had an almost working implementation 
> of spawn, except for a nasty compiler bug which resisted all efforts to 
> reduce it to a simple test case. Threads also required some clever work 
> with templates (testing arguments to "spawn" for sharing violations). I 
> implemented typelist.d in Phobos to make it easier, and learned how 
> inflexible D templates were. At least they are better than C++, or are 
> they?

I'm not that satisfied with D templates either. You can use them in 
mixins to achieve pretty amazing things, but I've been hindered by the 
visibility rules with non-mixin templates and how templates with alias 
arguments are difficult to instantiate in certain contexts.

If it were me in charge of the D2 project, given the approaching 
deadline, I'd scrap the new concurrency model completely (including 
immutable, unless we are given a way to write safe constructor for it) 
and focus on everything else. In my view, that's better than leave it 
in the state it is now. (Note that I'm speaking of the model at the 
compiler level, creating new library code is a perfectly fine idea.)


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/