[dmd-concurrency] Defining shared delegates

[Andrei Alexandrescu]

Robert Jacques wrote:
> On Tue, 19 Jan 2010 17:47:54 -0500, Andrei Alexandrescu 
> <andrei at erdani.com> wrote:
>> I'm afraid there is no time for addressing data parallel computing. We 
>> simply don't have the resources. This may be a bummer, but it's the 
>> reality. One other real fact that is also a bummer is that the best 
>> way to add a great contribution to the language right now is to 
>> improve on the drafts that I'm sending, as opposed to discussing new, 
>> tall-order ideas. For draft 5 I only got three "act-on" comments, all 
>> from Steve.
>>
>> It will be great to discuss new and large-effort ideas once the book 
>> goes out. Can't wait. Until then, if you find a comma in the wrong 
>> font, let me know.
>>
>>
>> Andrei
> 
> This worries me a lot, because it feels like D will freeze after TDPL is 
> release. I understand that a lot of implementation won't be there, or it 
> may be buggy, but I'd really hate to have the core language simply not 
> support something.

We need to tread waters very carefully. I think the very last thing we 
want to do is publish things in the book that people try and discover 
don't work.

Maybe I didn't clarify the time line very well: after I deliver the 
manuscript, there will be a lag time due to publication overheads of 2-3 
months. That should give us the time to make sure that everything the 
book claims works actually works. So by all means - if you're worried, 
this is the best time to do something about it.

> As for draft comments, spawn shouldn't be returning a thread id, it 
> should be returning a message box id, because message passing won't be 
> limited to OS threads, so your examples shouldn't imply that it is.

Actually it's good as it is. The types of messages accepted by threads 
are different from those accepted by processes.

> You 
> should also have an example using a separately created mailbox and an 
> CSP style alternative example where multiple mailboxes are waited upon.

Could you provide more detail? I don't know much about CSP, so in all 
likelihood I'll need to absorb some information first. (Fortunately Sean 
does.)

> As for data parallel computing in general, there are people working on 
> implementations, but I don't know how tight TDPL deadline is. But right 
> now, these implementations are completely unsafe. Some brainstorming and 
> code reviews lead to the idea that using a const/shared/immutable 
> delegate would allow for a mostly safe set of library functions. And it 
> seemed simple to define the taking the address of a const or shared 
> member function to generate a const or shared delegate; which would make 
> the library interface much cleaner. Anonymous shared/const delegate can 
> come later.

Ideally we should be able to devise rules that make it possible to use 
whatever paradigms we come up with in SafeD. Anything that's inherently 
uncheckable falls quite fast an interest cliff.


Andrei