Skip to content

Remove special case JS function proxying from library_pthread.c #16405

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 7 commits into from
Mar 6, 2022

Conversation

kleisauke
Copy link
Collaborator

@kleisauke kleisauke commented Mar 2, 2022

The normal __proxy method for JS functions works fine in these cases
and avoiding the special cases reduces the dependencies of
library_pthread.c which is included in all threaded programs.

@kleisauke kleisauke mentioned this pull request Mar 2, 2022
@kleisauke kleisauke force-pushed the remove_special_case_proxying branch 2 times, most recently from bf4e1b0 to 0f1095f Compare March 2, 2022 15:24
case EM_PROXIED_CREATE_CONTEXT:
q->returnValue.i = emscripten_webgl_create_context(q->args[0].cp, q->args[1].vp);
break;
#ifdef __EMSCRIPTEN_OFFSCREEN_CANVAS__
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Creating another libc variant purely for this purpose seems rather unfortunate.

Can we leave this in unconditionally for now, and submit PR that just removes the EM_PROXIED_CREATE_CONTEXT? Then we can figure out how to somehow
incject this handler only when OFFSCREEN_CANVAS is enabled as a followup?
Perhaps we can do it via some kind of dependency injections of extension mechanism
for _do_call?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted for now with commit 815f592. I'm not sure what the best way is to handle this.

#if !MINIMAL_RUNTIME
'$handleException',
#endif
],
Copy link
Collaborator

@sbc100 sbc100 Mar 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this unrelated?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This NFC change (commit 0f1095f) was found while working on this, but is indeed unrelated. Let me know if you want to revert that too (for now).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this code calls the _exit C function so I don't understand how removing the dependency can be correct?

In any case please split this out into a separate change.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These dependencies are also defined in $PThread__deps, so it's just de-duplicating the deps here.

$PThread__deps: ['_emscripten_thread_init',
'$killThread',
'$cancelThread', '$cleanupThread', '$zeroMemory',
'$ptrToString', '$spawnThread',
'_emscripten_thread_free_data',
'exit',
#if !MINIMAL_RUNTIME
'$handleException',
#endif
],

I'll revert this change for now.

@@ -1 +1 @@
47521
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a pretty nice size reduction!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I managed to reduce it even more with commit b3beb21.

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you give this PR the correct title and description and then I think we can land this.

@kleisauke kleisauke changed the title Rebased version of PR #14912 Ensure library_pthread.c does not include more JS dependencies than necessary Mar 4, 2022
@kleisauke kleisauke force-pushed the remove_special_case_proxying branch from 82751c5 to 495f493 Compare March 4, 2022 10:10
@kleisauke
Copy link
Collaborator Author

PR description and title were updated as requested.

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

sbc100 and others added 7 commits March 6, 2022 12:59
The normal `__proxy` method for JS functions works fine in these cases
and avoiding the special cases reduces the dependencies of
`library_pthread.c` which is included in all threaded programs.
i.e. when building with `-sOFFSCREENCANVAS_SUPPORT=0` (default)
@kleisauke kleisauke force-pushed the remove_special_case_proxying branch from 495f493 to 67bac98 Compare March 6, 2022 12:18
@kleisauke kleisauke changed the title Ensure library_pthread.c does not include more JS dependencies than necessary Remove special case JS function proxying from library_pthread.c Mar 6, 2022
@sbc100 sbc100 merged commit a18bbf7 into emscripten-core:main Mar 6, 2022
@kleisauke kleisauke deleted the remove_special_case_proxying branch March 6, 2022 16:42
sbc100 added a commit that referenced this pull request Dec 2, 2022
The dependency wrangling here was a workaround for a problem that was
solved in #16405 (see the command that is being deleted).

Pretty much all the functions in this depend either directly or
indirectly on the global GL object, so it makes sense to use autoAddDeps
rather than try to add individual deps.
sbc100 added a commit that referenced this pull request Jan 23, 2023
This family of function was not used anywhere can not currently usable
externally.

The core function `emscripten_sync_run_in_main_thread` was not usable
since the its first argument is `em_queued_call` which is not struct
that is declared externally.

The `emscripten_sync_run_in_main_thread_N` function all take a function
index as arg0 which is a index in to the JS function table which is not
known statically, and is an implementation of detail of JS library
proxying.

It looks like these function were once used by JS library code but the
last remaining use of them was removed in #16405.
sbc100 added a commit that referenced this pull request Jan 23, 2023
This family of function was not used anywhere and is not currently
usable externally.

The core function `emscripten_sync_run_in_main_thread` was not usable
since the its first argument is `em_queued_call` which is not struct
that is declared externally.

The `emscripten_sync_run_in_main_thread_N` function takes a function
enum as arg0 which is not designed to be user facing.

It looks like these function were once used by JS library code but the
last remaining use of them was removed in #16405.

See: #15756
sbc100 added a commit that referenced this pull request Jan 23, 2023
…18580)

This family of functions was not used anywhere within the codebase
and is not currently usable externally.

The core function `emscripten_sync_run_in_main_thread` was not usable
since the its first argument is `em_queued_call` which is not struct
that is declared externally.

The `emscripten_sync_run_in_main_thread_N` functions takes a function
enum as arg0 which is not designed to be user facing.

It looks like these function were once used by JS library code but the
last remaining use of them was removed in #16405.

See: #15756
sbc100 added a commit that referenced this pull request Apr 18, 2023
The dependency wrangling here was a workaround for a problem that was
solved in #16405 (see the command that is being deleted).

Pretty much all the functions in this depend either directly or
indirectly on the global GL object, so it makes sense to use autoAddDeps
rather than try to add individual deps.
sbc100 added a commit that referenced this pull request Apr 18, 2023
The dependency wrangling here was a workaround for a problem that was
solved in #16405 (see the command that is being deleted).

Pretty much all the functions in this depend either directly or
indirectly on the global GL object, so it makes sense to use autoAddDeps
rather than try to add individual deps.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants