Am Sun, 19 Oct 2014 17:09:22 +0000 schrieb "Sean Kelly" <s...@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
