std.concurrency.spawn does not accept delegates

[Steven Schveighoffer]

On Tue, 19 Jul 2011 14:31:19 -0400, Jonathan M Davis <jmdavisProg at 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