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
