Skip to content
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

New threads should receive DSO module via postMessage #18552

Closed
sbc100 opened this issue Jan 18, 2023 · 2 comments · Fixed by #19390
Closed

New threads should receive DSO module via postMessage #18552

sbc100 opened this issue Jan 18, 2023 · 2 comments · Fixed by #19390
Assignees

Comments

@sbc100
Copy link
Collaborator

sbc100 commented Jan 18, 2023

Right now we compile side modules on each thread but for module that have already been loaded at thread creation time this is not necessary.

@sbc100 sbc100 self-assigned this Jan 18, 2023
@dschuff
Copy link
Member

dschuff commented Mar 2, 2023

I guess the way this would work is that whenever a thread compiles a module it should postMessage that module to the other threads before loading (would this have to bounce through the main thread?). The onmessage handler would just stash the module in a data struct somewhere. When dlopen runs, it would check whether the module has already been received from another thread.
This would not help threads which just run in an infinite loop and never return to the event loop (they can still load the code because sync XHR and sync loading is allowed on workers, but they have no way to receive modules from other threads).

@sbc100
Copy link
Collaborator Author

sbc100 commented Mar 9, 2023

I'm working on this change now, and I'm trying to figure out how best to test it. Its tricky because its supposed to be un-observable to the user when a given pthread loads the module.

Any ideas for how to write this kind of test?

sbc100 added a commit that referenced this issue Mar 10, 2023
Also test the preload plugin system under node.  I was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue Mar 10, 2023
Also test the preload plugin system under node.  I was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue Mar 11, 2023
Also test the preload plugin system under node.  I was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue Mar 14, 2023
Also test the preload plugin system under node.  I was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue Mar 15, 2023
Also test the preload plugin system under node.  I was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue Mar 15, 2023
Also test the preload plugin system under node.  I was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 2, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 2, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 3, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 3, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 3, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 3, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 3, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 3, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 4, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 8, 2023
Also test the preload plugin system under node.  It was working
previously but not covered by any of the test we run in CI.

I'm hoping to unify this preloading system with the one planned as
part of #18552.
sbc100 added a commit that referenced this issue May 24, 2023
Any side modules that are loaded at the time of worker creation are
shared with the worker via the initial postMessage.

As a followup we should extend this to modules that are loaded after
the worker is created but before the pthread runs (for example when
a module is loaded while a worker is unused).

Fixes: #18552
sbc100 added a commit that referenced this issue May 25, 2023
Any side modules that are loaded at the time of worker creation are
shared with the worker via the initial postMessage.

As a followup we should extend this to modules that are loaded after
the worker is created but before the pthread runs (for example when
a module is loaded while a worker is unused).

Fixes: #18552
sbc100 added a commit that referenced this issue May 25, 2023
Any side modules that are loaded at the time of worker creation are
shared with the worker via the initial postMessage.

As a followup we should extend this to modules that are loaded after
the worker is created but before the pthread runs (for example when
a module is loaded while a worker is unused).

Fixes: #18552
sbc100 added a commit that referenced this issue May 25, 2023
Any side modules that are loaded at the time of worker creation are
shared with the worker via the initial postMessage.

As a followup we should extend this to modules that are loaded after
the worker is created but before the pthread runs (for example when
a module is loaded while a worker is unused).

Fixes: #18552
sbc100 added a commit that referenced this issue May 25, 2023
Any side modules that are loaded at the time of worker creation are
shared with the worker via the initial postMessage.

As a followup we should extend this to modules that are loaded after
the worker is created but before the pthread runs (for example when
a module is loaded while a worker is unused).

Fixes: #18552
sbc100 added a commit that referenced this issue May 25, 2023
Any side modules that are loaded at the time of worker creation are
shared with the worker via the initial postMessage.

As a followup we should extend this to modules that are loaded after
the worker is created but before the pthread runs (for example when
a module is loaded while a worker is unused).

Fixes: #18552
sbc100 added a commit that referenced this issue May 26, 2023
Any side modules that are loaded at the time of worker creation are
shared with the worker via the initial postMessage.

As a followup we should extend this to modules that are loaded after
the worker is created but before the pthread runs (for example when
a module is loaded while a worker is unused).

Fixes: #18552
sbc100 added a commit that referenced this issue May 26, 2023
Any side modules that are loaded at the time of worker creation are
shared with the worker via the initial postMessage.

As a followup we should extend this to modules that are loaded after
the worker is created but before the pthread runs (for example when
a module is loaded while a worker is unused).

Fixes: #18552
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 a pull request may close this issue.

2 participants