• Jason House <jason.james.house gmail.com> May 14 2009
• "Robert Jacques" <sandford jhu.edu> May 14 2009

Jason House <jason.james.house gmail.com> writes:

Robert Jacques Wrote:

 On Thu, 14 May 2009 02:13:37 -0400, Walter Bright  
 <newshound1 digitalmars.com> wrote:
 
 Robert Jacques wrote:
 I agree for POD, but what classes where the synchronization is  
 encapsulated behind a virtual function call?


 synchronization can make a shared reference "tail shared".


 I agree, but that doesn't seem answer my question. Put another way, if I  
 have an interface I which is implemented by both a thread local class L  
 and a shared class S, then does some function F need to know about whether  
 the implementor of I is S or L?


Shared data needs fundamentally different handling than thread local data. I
expect "shared I" and "__thread I" to be handled differently. You can't store
an S where an L is expected... It can break code.
 
 P.S. There will obviously be some interfaces S can't implement, but that a  
 separate issue.
 
 Also, does this mean 'scope' as a type is going away?






Of course not. Scope storage class will remain.
 Scope never was a type, it's a storage class.


 Sorry for the confusion of terminology. However, you talk blog about using  
 the 'scope' keyword to support escape analysis, ettc. i.e. 'scope' would  
 become the 'const' of the shared-thread local-stack storage type system.  
 Is this still the plan?

"Robert Jacques" <sandford jhu.edu> writes:

On Thu, 14 May 2009 08:51:37 -0400, Jason House  
<jason.james.house gmail.com> wrote:

 Robert Jacques Wrote:

 On Thu, 14 May 2009 02:13:37 -0400, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Robert Jacques wrote:
 I agree for POD, but what classes where the synchronization is
 encapsulated behind a virtual function call?


 synchronization can make a shared reference "tail shared".


 I agree, but that doesn't seem answer my question. Put another way, if I
 have an interface I which is implemented by both a thread local class L
 and a shared class S, then does some function F need to know about  
 whether
 the implementor of I is S or L?


 Shared data needs fundamentally different handling than thread local  
 data. I expect "shared I" and "__thread I" to be handled differently.  
 You can't store an S where an L is expected... It can break code.

 P.S. There will obviously be some interfaces S can't implement, but  
 that a
 separate issue.

 Also, does this mean 'scope' as a type is going away?






 Of course not. Scope storage class will remain.


The use of scope I'm talking about (see below) isn't even implemented yet,  
so how can it remain? It was Walter bogged a while ago about using the  
scope keyword to aid escape analysis, which would provide a common type  
for shared-local-stack allocation. I'm not referring to the use of 'scope'  
to stack allocate a class.

 Scope never was a type, it's a storage class.


 Sorry for the confusion of terminology. However, you talk blog about  
 using
 the 'scope' keyword to support escape analysis, ettc. i.e. 'scope' would
 become the 'const' of the shared-thread local-stack storage type system.
 Is this still the plan?