The "no gc" crowd

[Jacob Carlborg]

On 2013-10-11 02:51, Jonathan M Davis wrote:

> At this point, I don't see how we can have thread-local pools unless casting
> to and from shared has hooks for managing that. Otherwise, it's far too likely
> that an object is going to be in the wrong pool, because it's being used as
> shared when it was constructed as thread-local or vice versa. And we may need
> some sort of hook with std.concurrency.send which understands that the object
> being sent is being transferred from one thread to another and would tell the
> GC to migrate the object from one pool to another (though to do that, it would
> probably have to not be typed as shared but rather as thread-local, which
> would jive better with what you're talking about doing with std.concurrency).
>
> Certainly, with how shared currently works, it's hard to see how we could get
> away with having thread-local GC pools as great as that would be. So, if we
> want that, something about how shared works is going to have to change.

A simple solution to the "hook" would be to pass a dummy type indicating 
the object should be transferred:

struct Transfer { }

send(tid, foo, Transfer());

"Transfer" would be defined in std.concurrency.

-- 
/Jacob Carlborg