core: refactor how libuv companion objects are allocated #553
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All native bindings are allocated and attached to the JS object in an opaque.
When what we attach is a native binding to a libuv handle there is a tricky situation: uv_close() is not synchronous, which means that we need to delay freeing the native object until the close callback was called. This is a problem when objects are freed as part of freeing the JS engine, since by the time the close callback is called the JS context and runtime have been freed.
In order to avoid this problem, allocate the memory for these "companion" objects with the tjs__ family of functions, which don't depend on the JS context.
This also allows us to refactor TJSFreeRuntime to a much more obvious flow. There is no need to walk and close all libuv handles, since they'll all be closed when the JS engine is terminated.