Use a special metatable for thread userdata arguments #728
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.
This is a proposal for handling thread and async userdata arguments.
The current implementation copies the userdata block of raw memory, sets the same metatable then removes it after the callback.
This implementation requires the userdata usage to be thread-safe and not used after the callback.
As far as I see the main use case for passing userdata consists in passing async to the thread callback.
It is not possible to check if a userdata is thread-safe.
The userdata cannot be used after the callback which is fine for thread but not for async.
This change consists in letting the caller opt-in to pass the metatable by providing a dedicated metatable suffixed
_ref
.Such metatable is provided for
uv_async
with no close nor gc.There is still a major issue as the async could be garbage collected on the main side.
Another option would be to forbid all userdata arguments except async or not setting the metatable at all.