On Wednesday, 26 June 2013 at 14:26:03 UTC, H. S. Teoh wrote:
Yeah, I think the best approach would be one that doesn't
require
changing a whole mass of code to support. Also, one that
doesn't require
language changes would be far more likely to be accepted, as
the core D
devs are leery of adding yet more complications to the language.
That's why I proposed that gc_alloc and gc_free be made into
thread-global function pointers, that can be swapped with a
custom
allocator's version. This doesn't have to be visible to user
code; it
can just be an implementation detail in std.allocator, for
example. It
allows us to implement custom allocators across a block of code
that
doesn't know (and doesn't need to know) what allocator will be
used.
Yes, being able to change gc_alloc, gc_free would do the work. If
runtime remembers the stack of gc_alloc/gc_free functions like
pushd, popd, that would simplify its usage.
I think this is a very nice and simple solution to the problem.
