D2 Multithreading Architecture

[Robert Jacques]

On Wed, 29 Apr 2009 08:53:16 -0400, Jason House  
<jason.james.house at gmail.com> wrote:

> Robert Jacques Wrote:
>
>> On Tue, 28 Apr 2009 22:12:41 -0400, Daniel Keep
>> <daniel.keep.lists at gmail.com> wrote:
>>
>> >
>> >
>> > Andrei Alexandrescu wrote:
>> >> Robert Jacques wrote:
>> >>> Repost in ascii, since utf-8 has been causing some issues.
>> >>
>> >> You should know that posting a long, serious proposal here has less
>> >> chances than the paper -> bottle -> ocean route. A month from now it
>> >> will be forgotten.
>> >>
>> >> Please post in a wiki/blog/webpage.
>> >>
>> >>
>> >> Andrei
>> >
>> > Mostly because this teeny tiny window I read NG postings through  
>> doesn't
>> > work for long posts.  Plus, Thunderbird doesn't support my
>> > Text-to-speech addon.
>> >
>> > Why not whack it up on the D wiki?
>> >
>> >   -- Daniel
>>
>> I just did. :)
>> http://www.prowiki.org/wiki4d/wiki.cgi?OwnershipTypesInD
>
> A link to an overview of GRFJ would be helpful.
>
> The largest issue I see is using scope as any kind of output parameter.  
> If I pass a variable in as a ref scope parameter, all type information I  
> had must be erased. Any assignment to the head of the scope variable  
> could be an incorrect type. For example, a local variable could be  
> transformed into a shared variable. (both are scope inside the function  
> call). This leads to a cascade of issues I have with the proposal, so  
> I'll stop here and get your thoughts.  Const scope isnot an issue, but I  
> think you aim to handle more than that.

I've adding a link to Bartosz's GRFJ summary:  
http://bartoszmilewski.wordpress.com/2009/03/30/generic-types-for-concurrency/

Indeed I intend to handle more than that. The simple answer is that you  
can not assign to a scope variable except at declaration. This is scope  
rule 2. But this basically prevents output parameters (for exactly the  
reasons you mentioned). However, I think you are referencing to the  
section on the relaxation of rule two, which allows limited use of output  
parameters. This relaxation works by recognizing that the head of scope  
variables _must_ exist on the stack. Thus it is safe (with a few  
exceptions, see scope rule 6) to swap them. However, assigning to anywhere  
off the stack could result in the escape you mentioned and hence is  
illegal:
scope Node ln = myLocalNode;
scope Node sn = mySharedNode;
swap(sn,ln);       // Okay, were are only swapping the local scope  
references that exist on the stack
swap(sn, ln.next); // Error: Cannot take the reference of a scope tail