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.
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
Web optimizations #559
Web optimizations #559
Changes from 8 commits
1dbda17
d804258
b2ab9a1
02507fe
dcd8f4a
e024029
6feb9b7
65ba727
055a7c2
ec6f289
cf72d6c
e5d68a9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I initially avoided using
globalThis
here because I have no idea how it works exactly on Node.js. In the meantime I have looked up the documentation and asked around: it should be perfectly fine to useglobalThis
in Node.js.For context: the current setup just accesses the object directly from the global scope. According to the spec this is perfectly fine. However, this is usually discouraged because global variables can simply be overwritten. While I'm not sure if there is more history behind this, fact is that read-only properties like
crypto
can't be overwritten. So both approaches, accessingCrypto
through the globalcrypto
variable orglobalThis.crypto
, will work the same.But to stick with "how it should be done" I will add
globalThis
now.EDIT: Support should also not be a concern after #554, but you can make your own evaluations via "Can I Use".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of using methods,
static
s, andthread_local_v2
, can we usejs_namespace
like:(I'm not sure if
js_namespace
should becrypto
or["globalThis", "crypto"])
).Then the code can just be:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are forfeiting the check if
Crypto
is available though.But if your intention was just to get rid of the nesting, how about prefacing the function like this:
Let me know how you want to proceed.
My recommendation is to keep the check in place, there's all sort of strange JS environments out there,
getrandom
is very foundational and should support these imo. AndCRYPTO
is cached after all so there is no performance overhead.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking if the global
crypto
object exists doesn't really change what platforms/environments we support. It just changes what error message we get when the call tocrypto.getRandomValues
fails. Before, we were checking for existence of the object as part of our platform detection (and to cache the value inRngSource
). Now that we don't have two different implementations for Web vs Node, we don't need to do any of that.So if I'm understanding things correctly, having the check for the existence of the object just lets us return
Error::WEB_CRYPTO
to the user, informing them that"Web Crypto API is unavailable"
instead of my implementation above which would make us returnError::WEB_GET_RANDOM_VALUES
in all places.I think returning good error messages is valuable, so I think keeping some sort of check is OK, provided that we aren't making an additional FFI call every time (which I don't think we do because the result of
is_none
is cached).I personally find the un-nested version easier to read, so we might try a version that avoids too much nesting (potentially by using a helper function).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you are relying on the fact that WBG just catches any exception when tagging it with
catch
. While this is currently the case, its not intended to be used like this. Ideally, this would only catch exceptions thrown by the function call. However, I guess this behavior has to stay in place because otherwise it would be a breaking change.Sure!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, let me know if you like this better!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see!
From my understanding the issue was getting rid of the nesting, but that has been achieved, right? Is there some other motivation to get rid of
thread_local_v2
?On that note: your proposal will store the check globally. But different threads may have different outcomes. This isn't hypothetical either, some worklets don't have access to
Crypto
. So this needs to be in a thread-local to work correctly.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not familiar with the
wasm-bindgen
inner workings, but wouldn'tjs_namespace
-based code result in a lighter-weight WASM file? Plus, the resulting source code will be slightly smaller, assuming that we do not care about theWEB_CRYPTO
error. If we want to keep it, then I think the current code is fine.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we have one FFI function less present in the Wasm file. To put it into perspective: the function that actually ends up in the Wasm file after post-processing is done is just a single FFI signature, one byte cast and an if condition. Not counting the storing and loading ofc.
If you don't care about the
WEB_CRYPTO
error yes, then we can simply go with the original proposal by @josephlr. I will do some digging into the specification and actually find out ifCrypto.getRandomValues()
can realistically fail or not actually.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, that fast: according to the specification,
Crypto.getRandomValues()
can only fail if we don't supply the right buffer type or we exceed the maximum byte length of 65536. So instead of getting rid ofWEB_CRYPTO
I will go ahead and get rid ofWEB_GET_RANDOM_VALUES
.Let me know what you think!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 8cf6832.