[emval] Add unique_val
analog to be have like a std:unique_ptr
version of val
.
#21433
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.
Following from explorations in #20447 and #21300, it may be that the simplest approach to reducing JS/C++ overhead for reference counting is to simply use move-able instances more.
One way to encourage this would be to have a class similar to
std::unique_ptr
to force move-semantics and singular ownership of a handle.At the moment this is a proof of concept for this:
It carves out a base class
base_val
with no public constructor to capture the static factory functions and methods to operate with eitherval
orunique_val
It changes all the return types of these methods and factories to return
unique_val
to encourage its use.unique_val
has no copy constructor/assignemtn, only move.val
has implicit constructor fromunique_val
that will do the incref to have a second reference in C++. This allows the return value change to be safe with existing code expectingval
.It's not clear to me at the moment if this is valuable, or if it's best to just encourage the use of std::move with
val
as is.If this direction is useful, I wonder if the analogy to standard library smart pointers could be made stronger with different names:
emscripten::unique_js_ptr
andemscripten::shared_js_ptr
.emscripten:vall
would then be an alias foremscripten::shared_js_ptr
. theshared_js_ptr
could build on #21300 to further minimize overhead.Leaving this as draft -- I don't have any urgent need to make this more efficient, and don't have the bandwidth to push for a big refactor here. Just adding here to share thoughts for future work.
@RReverser