On Sunday, 30 August 2015 at 21:59:59 UTC, ponce wrote:
I'm not sure there is even a need for synchronization since
other threads that wan't to allocate try to take the GC lock
while the GC-hijacked thread calls destructors.
And if the destructor isn't called by the GC, I don't see a
problem either.tre
I'd like to point out that this problem is showing up in the
design of std.experimental.allocator. Any allocator that
deallocates its memory in a destructor cannot a) use GCAllocator
(directly or indirectly) and b) be used by CAllocatorImpl
at the same time.
As of right now there's no compile-time check that disallows this
and there is no way for the allocators to know that they
shouldn't do things like call deallocateAll() on an allocator
when the GC is running.
