-
-
Notifications
You must be signed in to change notification settings - Fork 653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split get typed array methods in loader to safe and unsafe (view) #1047
Split get typed array methods in loader to safe and unsafe (view) #1047
Conversation
The intended use here is something like const arrPtr = wasm.__retain(wasm.__allocArray(...));
const outPtr = wasm.callSomeMethod(arrPtr);
const ret = wasm.__getUint8Array(outPtr);
wasm.__release(arrPtr);
return ret;
// if `outPtr` somehow references `arrPtr`, its RC remains >0 until `outPtr` is released with Also iirc, the |
const arrPtr = wasm.__retain(wasm.__allocArray(...));
const outPtr = wasm.callSomeMethod(arrPtr);
const ret = wasm.__getUint8Array(outPtr);
wasm.__release(arrPtr);
return ret; This produce the same result) |
In the case that const arrPtr = wasm.__retain(wasm.__allocArray(...)); // RC(arrPtr)=1
const outPtr = wasm.callSomeMethod(arrPtr); // RC(outPtr)=1 due to return, RC(arrPtr)=2
const ret = wasm.__getUint8Array(outPtr);
wasm.__release(arrPtr); // RC(arrPtr=1)
return ret;
// later
__release(outPtr); // RC(outPtr)=0, releasing its refs, then RC(arrPtr)=0 This is not so much about what method is called with |
This not works and still required Also @torch2424 came across to similar problem as I know |
The example you linked doesn't work (in the modified form below) because const digestPointer = wasm.digest();
const digest = wasm.__getUint8Array(digestPointer)/* .slice() */;
wasm.__release(digestPointer);
return digest; prematurely releases the reference while So far I was under the impression that not having to slice and instead keeping stuff alive is what we want there to achieve maximum perf. |
ChainSafe/as-sha256#23 (comment) In general it cause to problems so I prefer use safe but with little extra overhead instead by default instead potentially danger method which works right only partially in specific cases |
Perhaps it would make sense to have two different API methods there
Maybe it's just confusing naming the way it is? |
Yeah, I agree with naming. Will rename |
Also note that if such a function copies by default, we lose mutability in both ways. Without copying, one can see changes and make changes, while with copying it's rather a readonly snapshot. |
Speaking of naming, I also like the term |
I prefer leave |
Would say we are breaking backwards compatibility anyway for everyone using the existing API to modify data in either way, since |
I see. But still think it better leave "as is". Btw comment notation emphasise that |
Using
__getUint8Array
and other method lead to confusion because it require imeddiate usage of results before other allocs or deallocs. Overwise memory buffer will outdated and point to non-relevant data. Like:This PR make
__getUint8Array
and other methods safe by default by cloning and add new methods like__getUint8ArrayView
which preserve previous dangers behaviour (without cloning)