RData types should be able to interact with the active Runtime in their destructor. For example, a Sprite rdata may wish to deregister itself from the Graphics lib when the user calls (free! the-spr).
Currently, when a Runtimeis dropped, it deinitializes all Libs before cleaning up any RData on the heap, and it holds dynamic borrows of certain data structures internal to the GC heap while running RData destructors. This means that practically any interaction with the active Runtime will panic.
The fix will be to have a separate pass where all RData on the heap are freed (as though using the built-in function free!) before doing any other cleanup - in particular, before dropping any Libs.
If possible, we should also add dynamic checks to forbid any RData from calling glsp::add_lib or glsp::rdata in their destructor.
fleabitdev
commented
4 years ago
RDatatypes should be able to interact with the activeRuntimein their destructor. For example, aSpriterdata may wish to deregister itself from theGraphicslib when the user calls(free! the-spr).Currently, when a
Runtimeis dropped, it deinitializes allLibsbefore cleaning up anyRDataon the heap, and it holds dynamic borrows of certain data structures internal to the GC heap while runningRDatadestructors. This means that practically any interaction with the activeRuntimewill panic.The fix will be to have a separate pass where all
RDataon the heap are freed (as though using the built-in functionfree!) before doing any other cleanup - in particular, before dropping anyLibs.If possible, we should also add dynamic checks to forbid any
RDatafrom callingglsp::add_liborglsp::rdatain their destructor.