The "no gc" crowd

[Jonathan M Davis]

On Thursday, October 10, 2013 10:55:49 Andrei Alexandrescu wrote:
> On 10/10/13 12:33 AM, Jonathan M Davis wrote:
> > 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
> 
> no
> 
> > 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.
> 
> yes

Really? Do you honestly expect the average use of shared to involve creating 
structs or classes which are designed specifically to be used as shared? That 
definitely has its use, but I would expect it to be far more common that 
someone would want to share the exact same types that they're using in their 
thread-local code. In fact, if anything, the normal responses to discussions 
on shared go in the complete opposite direction of creating classes which are 
designed to work as shared. It seems like the normal thing to do is simply 
avoid shared altogether and use __gshared so that you don't have to deal with 
any of the problems that shared causes. Granted, I obviously haven't seen 
everyone's code, but I don't believe that I have ever seen anyone create a 
type designed to be used as shared, and that's certainly not what people 
discuss doing when shared comes up. TDPL discusses that - and again, I do 
think that that has its place - but I've never seen it done, and I've never 
run into any place in my own code where I would have even considered it. 
Usually, you want to share an object of the same type that you're using in 
your thread-local code.

And even if a struct or class is set up so that its member functions work 
great as shared, very little code seems to be written with shared in mind 
(since thread-local is the default), so the only functions which will work 
with it are its member functions, functions written specifically to work with 
that type, and templated functions that happen to work with shared. As such, I 
fully expect casting away shared to be a very common idiom. Without that, the 
number of things you can do with a shared object is very limited.

> > Far more frequently, you want to share a type which you would also
> > use normally as a thread-local variable, and that means casting.
> 
> no

What else do you expect to be doing with std.concurrency? That's what it's 
_for_. Unless all of the stuff that you're passing across threads are value 
types or are designed to work as immutable or shared (which most types 
aren't), the objects which get passed across need to be cast to thread-local 
mutable on the target thread in order to be used there, and if you have to do 
much of anything with the object other than constructing it before passing it 
across, then you're going to have to have it as thread-local on the 
originating thread as well, because most functions are going to be unusable 
with shared.

- Jonathan M Davis