-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Always fixup custom __proxy
attributes in library_html5_webgl.js
#20135
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
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
This is awkward, no? Wouldn't all other libraries besides
library_htm5_webgl.js
want to run this functionality as well to ignore proxy attributes?Ideally for Wasm Workers, the
__proxy
mechanism should be ignored if function is called from main thread, and in assertions builds, if a proxied JS function is called from a Wasm Worker, the code would raise an error, and in release builds simply truck through?That is what this code
emscripten/src/jsifier.js
Lines 247 to 255 in 3a55fe1
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.
This code only runs if
!SHARED_MEMORY
so when building with wasm workers or pthreads this code doesn't run and the attributes are not ignored.I agree this could probably use a comment. The issue is that
library_htm5_webgl.js
uses custom__proxy
addributesync_on_webgl_context_handle_thread
which needs to get either re-written (above), or removed (here) before the library is processed, otherwise we get anInvalid proxyingMode
jsifier.Uh oh!
There was an error while loading. Please reload this page.
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.
Oh, I did already include a comment as to why this done. Does it make sense now, given my explanation?
My initial version of this attempted to relax the
__proxy
checking but @kripken suggested we always remove / rewrite the custom values instead: #20135 (comment)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 confused. Taking a closer look, the code runs if
but I think I wrote that when I still had the assumption that PTHREADS and WASM_WORKERS would always be mutually exclusive and you'd only build targeting one or the other - but turns out targeting both at the same time made sense.
So that above code should instead be
so that in PTHREADS + WASM_WORKERS builds the assertion is also added. Would that appropriately resolve the issue?
I still think no library_x.js file should need to mutate the __proxy fields depending on the build mode.
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 think I see what you are saying. We should probably not erase the __proxy attributes in the wasm workers build. I will create a followup to do that.
I agree the custom proxy stuff in
library_html5_webgl.js
is unusual but it looks like you were the one that created this mechanism back in #11356, and I think its OK as long as it get locally handled/erased.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.
Sorry, I mis-remembered, I already did do that in this PR, that
__proxy
handling is enabled here for allSHARED_MEMORY
builds.I think updating jsifier.js in way you suggest sounds fine to me. That seems like a pre-existing issue that is somewhat unrelated to this PR and would effect all libraries, right?
Are you happy with this PR in the way it deals with
library_html5_webgl.js
?Uh oh!
There was an error while loading. Please reload this page.
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.
Yeah, I think it would be very preferable to have that affect all libraries, so that any developer who is calling a
__proxy: sync
function inside a Wasm Worker would get an assertion firing on them. That is because I don't think any function with that label would work properly when called in the context of a Wasm Worker.