Something needs to happen with shared, and soon.

[Jonathan M Davis]

On Thursday, November 15, 2012 10:22:22 Jacob Carlborg wrote:
> On 2012-11-14 22:06, Walter Bright wrote:
> > I hate to repeat myself, but:
> > 
> > Thread 1:
> >      1. create shared object
> >      2. pass reference to that object to Thread 2
> >      3. destroy object
> > 
> > Thread 2:
> >      1. manipulate that object
> 
> Why would the object be destroyed if there's still a reference to it? If
> the object is manually destroyed I don't see what threads have to do
> with it since you can do the same thing in a single thread application.

Yeah. If the reference passed across were shared, then the runtime should see 
it as having multiple references, and if it's _not_ shared, that means that 
you cast shared away (unsafe, since it's a cast) and passed it across threads 
without making sure that it was the only reference on the original thread. In 
that case, you shot yourself in the foot by using an @system construct 
(casting) and not getting it right. I don't see why the runtime would have to 
worry about that.

Unless the problem is that the object is a value type, so when it goes away on 
the first thread, it _has_ to be destroyed? If that's the case, then it's a 
pointer that was passed across rather than a reference, and then you've 
effectively done the same thing as returning a pointer to a local variable, 
which is @system and again only happens if you're getting @system wrong, which 
the compiler generally doesn't protect you from beyond giving you an error in 
the few cases where it can determine for certain that what you're doing is 
wrong (which is a fairly limited portion of the time).

So, as far as I can see - unless I'm just totally missing something here - 
either you're dealing with shared objects on the heap here, in which case, the 
object shouldn't be destroyed on the first thread unless you do it manually (in 
which case, you're doing something stupid in @system code), or you're dealing 
with passing pointers to shared value types across threads, which is 
essentially the equivalent of escaping a pointer to a local variable (in which 
case, you're doing something stupid in @system code). In either case, it's 
you're doing something stupid in @system code, and I don't see why the runtime 
would have to worry about it. You shot yourself in the foot by incorrectly 
using @system code. If you want protection agains that, then don't use @system 
code.

- Jonathan M Davis