12-Sep-2014 15:03, monarch_dodra пишет:
I like the option of having "exception allocators" that can later be
explicitly called in a "release all exceptions" style, or plugged into
the GC, to be cleaned up automatically like any other GC allocated
exception. This would make the exceptions themselves still @nogc, but
the GC would have a hook to (potentially) collect them. For those that
don't want that, then they can make calls to the cleanup at
deterministic times.
This, combined with the fact that we used an (unshared) allocator means
the cleanup itself would be 0(1).
Finally, if somebody *does* want to keep exceptions around, he would
still be free to do so *provided* he re-allocates the exceptions himself
using a memory scheme he chooses to use (a simple GC new, for example).
... well, either that, or have each exception carry a callback to its
allocator, so that catch can do the cleanup, regardless of who did the
allocation, and how. GC exceptions would have no callback, meaning a
"catch" would still be @nogc. An existing code that escapes exceptions
would not immediately break.
Either way, some sort of custom (no-gc) allocator seems in order here.
Agreed.
I think that the total amount of live (not garbage) exceptions on heap
is small for any typical application. Thus just special casing the hell
out of exception allocation in the GC (and compiler) is IMO perfectly
satisfactory hack.
--
Dmitry Olshansky
