On Tue, 19 Jul 2011 14:31:19 -0400, Jonathan M Davis <jmdavisp...@gmx.com>
wrote:
On 2011-07-19 05:40, Steven Schveighoffer wrote:
On Mon, 18 Jul 2011 18:39:01 -0400, Jonathan M Davis I have to jump in
and correct you, nobody else has.
You can also pass data marked as shared.
A solution could be to cast the class as shared, pass it, then cast it
back to unshared (ensuring you don't access the class from the
originator
anymore).
This is not a compiler-enforced solution, but it gets the job done. But
there is risk of concurrency errors if you don't do it right. My
recommendation is to isolate the parts that create and pass the shared
data.
I thought that spawn and send disallowed shared and that you had to deal
with
shared separately, but if that's not the case, then that's not the case.
Regardless, you can't just pass anything with spawn or send (as the OP
seems
to be trying to do). They have restrictions to avoid concurrency bugs.
send requires the data pass this test:
!hasLocalAliasing!(T)
which maps to:
http://www.digitalmars.com/d/2.0/phobos/std_traits.html#hasUnsharedAliasing
So yes, you can pass shared data. However, there is still no sanctioned
way to "pass and forget" mutable unique thread-local data. That is, you
pass data to another thread, and it becomes local to that other thread
instead of to the thread passed from.
You are correct that you can't just pass anything (i.e. thread-local
mutable data), but in some cases, you have to force the issue. Just
because the compiler can't prove it's valid doesn't mean it isn't. But
it's definitely opening up a possibility for concurrency bugs.
-Steve
