On 11/14/2012 01:42 PM, Michel Fortin wrote:
On 2012-11-14 10:30:46 +0000, Timon Gehr <[email protected]> said:
On 11/14/2012 04:12 AM, Michel Fortin wrote:
On 2012-11-13 19:54:32 +0000, Timon Gehr <[email protected]> said:
On 11/12/2012 02:48 AM, Michel Fortin wrote:
I feel like the concurrency aspect of D2 was rushed in the haste of
having it ready for TDPL. Shared, deadlock-prone synchronized
classes[1]
as well as destructors running in any thread (thanks GC!) plus a
couple
of other irritants makes the whole concurrency scheme completely
flawed
if you ask me. D2 needs a near complete overhaul on the concurrency
front.
I'm currently working on a big code base in C++. While I do miss D
when
it comes to working with templates as well as for its compilation
speed
and a few other things, I can't say I miss D much when it comes to
anything touching concurrency.
[1]: http://michelf.ca/blog/2012/mutex-synchonization-in-d/
I am always irritated by shared-by-default static variables.
I tend to have very little global state in my code,
So do I. A thread-local static variable does not imply global state.
(The execution stack is static.) Eg. in a few cases it is sensible to
use static variables as implicit arguments to avoid having to pass
them around by copying them all over the execution stack.
private int x = 0;
int foo(){
int xold = x;
scope(exit) x = xold;
x = new_value;
bar(); // reads x
return baz(); // reads x
}
I'd consider that poor style.
I'd consider this a poor statement to make. Universally quantified
assertions require more rigorous justification.
"In a few cases" it is not, even if it is poor style "most of the time".
Use a struct to encapsulate the state, then make bar, and baz member functions
of that struct.
They could eg. be virtual member functions of a class already.
Using a local-scoped struct would work with pure,
It might.
be more efficient
Not necessarily.
(accessing thread-local variables takes more cycles),
It can be accessed sparsely, copying around the struct pointer is work
too, and the fastest access path in a proper alternative design would
potentially be even slower.
and be less error-prone while refactoring.
If done in such a way that it makes refactoring error prone, it is to be
considered poor style.
