GC-proof resource classes

[Brian Schott via Digitalmars-d]

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.