Issue #20290 has been updated by kjtsanaktsidis (KJ Tsanaktsidis). I'm positive on this idea in general, but I'd like the semantics of a) what extensions can/can't do inside this function, and b) what actions the extension is expected to take, nailed down a bit. * Are extensions supposed to undefine the Ruby constants they defined? (Seems like no, because https://github.com/ruby/ruby/pull/10055/files#diff-d1cee85c3b0e24a64519c1115... will walk the heap afterwards freeing things?) * Your implementation seems to imply to me that `dfree` functions for types owned by the module might still be called after `Destruct_` is called, which I think is surprising? * Are `Destruct_` methods allowed to call functions which might allocate? (looks like yes?) * What order are `Destruct_` methods called in? I would expect inverse order of `Init_` methods, but your implementation seems to walk the hash in insertion order? Have you got an example of a particular C extension which needs to free memory in this way? That might help me understand this a bit better. ---------------------------------------- Feature #20290: Add API for C extensions to free memory https://bugs.ruby-lang.org/issues/20290#change-106940 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/10055 Ticket #19993 added the new feature RUBY_FREE_AT_EXIT, which frees memory in Ruby at shutdown. This allowed tools like Valgrind, ASAN, and macOS leaks to find memory leaks in Ruby without a large number of false-positives outputted. However, this feature is not complete for C extensions, as they may also need to free their memory and there was no way to do so. This means that C extensions might not be able to directly use tools like Valgrind, ASAN, or macOS leaks to find memory leaks. This ticket proposes an API for C extensions to free memory by defining a function called `Destruct_<extension name>` that is called during shutdown when RUBY_FREE_AT_EXIT is enabled. This name mirrors the `Init_<extension name>` API that already exists for extension initialization. However, unlike the `Init_<extension name>` function, `Destruct_<extension name>` is NOT mandatory for the C extension to implement so that we can preserve backwards compatibility. -- https://bugs.ruby-lang.org/