After https://github.com/bytecodealliance/wasmtime/pull/2897 is merged, in the C API, the only finalizers that need to be called are finalizers for engine/store, right? I checked the examples and there are still calls to other finalizers present (e.g. linker) though
CC @Alex Crichton
@Cheng Shao mostly, yeah. Finalizers for func/table/instance/memory/global are all being removed since they no longer need to be finalized
modules/config/linker all still need finalization though
@Alex Crichton Thanks for answering! Also, is there still constraint that the finalizers must be run on the same system thread where they are created?
that constraint has been lifted! (one of the major goals of the RFC) -- all finalizers can be run concurrently on any thread
the main reason for that is that finalizers never finalize aliasing data, everything is entirely separately owned (e.g. a linker is entirely disconnected from a store)
(my intention is to cover all this in the documentation, which is yet-to-be-written at this point still)
Excellent news to hear! Thanks for all the hard work. Not before looking at the PR did I realize that there used to be such a constraint
It's not technically so restrictive that it has to be run from the original thread, only that store-related objects (e.g. stores, funcs, globals, memories, etc) must all be dropped on the same thread. They can all migrate somewhere else but it has to be all at once. This is such a fine point though that it's basically technically infeasible
So wasmtime doesn't actually use thread local storage, and as long as there are no concurrent usages from different threads, it doesn't matter where the methods are called?
more-or-less
nonatomic reference counting is used for Store objects today, which is basically the constraint
(but with the new API there's no reference counting at all, everything is separately owned, including the Store)
Last updated: Nov 22 2024 at 17:03 UTC