The "no gc" crowd

[Jonathan M Davis]

On Thursday, October 10, 2013 08:41:19 Jacob Carlborg wrote:
> On 2013-10-10 06:24, Jonathan M Davis wrote:
> > And given that std.concurrency requires casting to and from shared or
> > immutable in order to pass objects across threads, it seems ilke most of
> > D's concurrency model requires casting to and/or from shared or
> > immutable. The major exception is structs or classes which are shared or
> > synchronized rather than a normal object which is used as shared, and I
> > suspect that that's done fairly rarely at this point. In fact, it seems
> > like the most common solution is to ignore shared altogether and use
> > __gshared, which is far worse than casting to and from shared IMHO.
> 
> Isn't the whole point of std.concurrency that is should only accept
> "shared" for reference types? If you want to use std.concurrency create
> a "shared" object in the first place?

You might do that if you're creating the object simply to send it across, but 
it's frequently the case that the object was created well before it was sent 
across, and it frequently had to have operations done it other than simply 
creating it (which wouldn't work if it were shared). So, it often wouldn't 
make sense for the object being passed to be shared except when being passed. 
And once it's been passed, it's rarely the case that you want it to be shared. 
You're usually passing ownership. You're essentially taking a thread-local 
variable from one thread and making it a thread-local variable on another 
thread. Unfortunately, the type system does not support the concept of thread 
ownership (beyond thread-local vs shared), so it's up to the programmer to 
make sure that no references to the object are kept on the original thread, 
but there's really no way around that unless you're always creating a new 
object when you pass it across, which would result in which would usually be a 
unnecessary copy. So, it becomes like @trusted in that sense.

> > So, it's my impression that being able to consider casting to or from
> > shared as abnormal in code which uses shared is a bit of a pipe dream at
> > this point. The current language design pretty much requires casting when
> > doing much of anything with concurrency.
> 
> There must be a better way to solve this.

I honestly don't think we can solve it a different way without completely 
redesigning shared. shared is specifically designed such that you have to 
either cast it way to do anything with it or write all of your code to 
explicitly work with shared, which is not something that generally makes sense 
to do unless you're creating a type whose only value is in being shared across 
threads. Far more frequently, you want to share a type which you would also 
use normally as a thread-local variable, and that means casting.

- Jonathan M Davis