Le 06/10/2011 18:06, dsimcha a écrit :
I've been lurking a little on the recent discussions about thread-local
garbage collection and my general opinion is that implicitly thread-local GC
makes it too easy to shoot oneself in the foot if using non-SafeD constructs
like casting to shared/immutable or using std.parallelism or core.thread, and
that SafeD concurrency is so limited that it's not reasonable to expect people
to use only that.
However, what if we kept the shared GC as the default for everything **but
made thread-local GCs an allocator in the allocator interface that's being
worked on**? This probably wouldn't be hard to implement. All you'd need is
multiple instances of the GCX struct, one for each thread, and a way to
register the thread-local GCs with the shared GC so that pointers from the
thread-local GCs to shared memory get scanned properly and get rid of a little
locking/world stopping for the thread-local instances. Using the thread-local
GC allocator would be an explicit assertion that you will **not** be casting
the memory to shared/immutable and sharing it, using
core.thread/std.parallelism, etc. This would also keep with D's design
philosophy that the simple, safe way should be the default but the more
complicated, less safe way should be available for performance-critical code.
Thoughts?
The problem with the global GC is that it will stop all thread during
the whole collection. Having TL GC is interesting only if you have
mostly TL garbages.
So it would become necessary to use the allocator everywhere. Which
isn't very practical either.
IMO the solution should be done the other way around : if you want to do
casting as immutable or shared, to use thoses lib, you have to specify
it at allocation. cause you have to make sure anyway that data are
effectively immutable/shared compliant. This cannot be done without
knowing what you do anyway.
