[dmd-concurrency] Defining shared delegates

[Robert Jacques]

On Tue, 19 Jan 2010 16:20:43 -0500, Andrei Alexandrescu  
<andrei at erdani.com> wrote:
> Michel Fortin wrote:
>> Le 2010-01-19 à 15:20, Andrei Alexandrescu a écrit :
>>
>>> One suggestion about shared delegates: should we take the executive  
>>> decision to not define them at all? There's nothing you can do with  
>>> delegates that you can't do with classes. Although generally delegates  
>>> do justify their existence because they're more comfy than e.g. local  
>>> classes, it doesn't strike me as obvious we'll need comparable  
>>> convenience when dealing with shared classes.
>>  The reason I wrote all this is because I think delegates can be much  
>> easier to work with than classes. That's what I tried to demonstrate.
>>  That's because delegates completely encapsulate the "sharedness" of  
>> what they touch, which means that contrary to other types you can  
>> implicitly convert a shared delegate to a thread-local one. This should  
>> make them much easier to share than most other types, including classes.
>
> I may be missing something, but passing a delegate object across threads  
> begets arbitrary sharing of that delegate's state across threads -  
> because the delegate can do anything to its data. In fact, many  
> functional languages define poor man's classes as delegates that  
> dispatch the action depending on arguments. There are examples in e.g.  
> SICP (http://mitpress.mit.edu/sicp/).
>
> Andrei

Yes, I believe you are. You described a regular delegate that is shared  
between threads. What Michel and I have been talking about is a shared  
delegate, which can be safely passed between thread. A good example of  
what a shared delegate would be is the member function of a shared class,  
while a regular delegate is the member function of a normal class. i.e.  
the delegate's state would be protected in the same way any other shared  
object would be.