On Thu, 07 Jun 2012 22:16:21 -0400, Robert DaSilva <spunit...@yahoo.com>
wrote:
You're forgetting about Global data.
I wasn't so much forgetting it as I was ignoring it :)
My thought on that is that the shared keyword in that case is truly a
storage class. It's the one place where having a value-type based shared
value makes sense. If we had some kind of synchronized/shared pairing,
the compiler would have to allocate mutex space for that too.
I think rather the head shared should be striped as this fits better
with how D treats meaningless specifiers.
I don't think we can do that with type constructors, but I'm not sure.
I'm certainly against it, as I am against the current abuses of that
methodology.
And trying to put structs that contain shared data on the stack should
be illegal.
First, I can't imagine that you'd actually need a block on the heap that
was partially thread-local and partially shared. So allowing
partially-shared types does not make sense to me. For the cases where it
may make sense, a value-type + shared pointer might work, or a heap block
of TLS data which has a member pointing to another heap block of shared
data could make sense.
Can you think of good use cases that show it is important to have hybrid
blocks?
Second, I kind of like the idea that the monitor for the data in the block
protects the entire block. This would not make sense if part of the block
is not shared.
-Steve
