D2 Multithreading Architecture

[Jason House]

Robert Jacques Wrote:

> 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

My gut reaction is that this is too restrictive of a limitation. If someone can't call swap(n.a, n.b) for an arbitrary non-const type n, they will complain.