m_condition.mutex cannot be used in shared method ?

[Marco Leise via Digitalmars-d-learn]

Am Sun, 19 Oct 2014 17:09:22 +0000
schrieb "Sean Kelly" <sean at invisibleduck.org>:

> What really needs to happen is for everything in core.sync to be 
> made shared.  I got partway through this at one point and 
> stopped, because it was imposing a terrible design on the 
> classes--I had shared methods that were casting away shared and 
> then calling the non-shared methods to do the work.
> 
> The reason for this was that the transitivity of shared was 
> preventing me from calling pthread_mutex_lock or whatever because 
> those functions didn't take a shared pthread_mutex_t.  And 
> attempting to rewrite core.sys.posix to make the logically shared 
> types explicitly shared had a cascading effect that made me 
> uncomfortable.
> 
> Because of this, I remain unconvinced that the semantics of the 
> shared attribute are actually correct when applied to 
> user-defined types.  I want some kind of an "I know what I'm 
> doing" label, perhaps equivalent to the "mutable" attribute in 
> C++, but to exempt contained types from shared.

Thank you for that honest response. The situation is really
bizarre. I just tried to create a shared worker thread and
there is no ctor in Thread that creates a shared instance.

Is a shared constructor even meaningful? [1]
If yes, what do we need it for?

Can't we otherwise just implicitly and safely cast to shared
_after_ the constructor ran when we write `new shared(Foo)(...)`?

Casting away shared is not @safe. Since this is normal to
do in synchronized blocks, I figure the whole core.Thread and
core.sync.xxx family are @system functionality ?


[1]
(Note that I created a PR for DMD that disables shared
destruction:
https://github.com/D-Programming-Language/dmd/pull/4072)

-- 
Marco