On Saturday, 8 February 2014 at 03:11:17 UTC, Stanislav Blinov
wrote:
Ditto for other core.sync primitives.
This has been haunting me for a while now. Currently all those
guys are not qualified shared at all. What that means is that
we cannot use them in any shared classes:
shared class C
{
Mutex m;
this()
{
m = new Mutex; // error, cannot implicitly convert
Mutex to shared(Mutex)
m = new shared Mutex; // error, Mutex.this is not
callable using a shared object
}
}
Same goes for shared methods too. So the only possible ways to
use Mutex et al. are to either declare them __gshared, which
implies static, or apply casts. So we can't have per-instance
mutexes, condition variables, etc, unless using casts
everywhere.
As far as I can see this state is the same between dmd, ldc and
gdc.
So, question number 1:
Is this at all intentional or just inherent and no one got
around to adding support for shared? I can't at all see why
would they be non-shared.
Because if that is to change, it'd better be sooner than later,
right?
With mutexes the roots run as deep as object_.{d,di} where the
Monitor interface is declared (having both lock and unlock
methods non-shared).
I've been able to coerce my local pull of druntime to define
Mutex et al. as shared by default. Aside from sorcery with
casts inside e.g. src/gc/gc.d and combating segfaults in GC and
Thread initialization, it involved:
- qualifying Monitor's methods as shared
- renaming existing classes (e.g. class Mutex -> shared class
Mutex_)
- providing default-shared aliases (e.g. alias Mutex =
shared(Mutex))
The renaming and alias are needed to (a) not break existing
code and (b) because in my understanding they should be shared
anyway :)
Surprisingly, this didn't take all that long, though I suspect
there are some underwater rocks still remaining. But at least
both druntime and Phobos pass their unittests.
Thus, question number 2:
Am I going in the right direction, or is there something
already planned regarding this?
The complete set of changes would be rather large, as not only
it spans currently supported OSs, but I imagine also would
concern both druntime and Phobos (e.g. std.concurrency,
std.parallelism).
I am primarily on Linux, but given time I can also edit the
relevant files for Windows too. However, I don't have access to
any other OSs, so I still won't be able to create a complete
pull request.
Hence, question number 3:
Provided you've read to this point, and question number 2
yields positive answer, is there anybody willing to collaborate
on this? E.g. complete/test the changes on Windows, OSX, etc?
I understand that the community is currently battling in the
fields of GC vs ARC vs manual memory management, but I still
hope to hear your feedback :)
When I first time saw D language, I called it as my dream
language. Well, every nice thing has its problems. I hated that
"shared" keyword since first day. It ruins my codes whenever I
need to write multiple thread programs.
