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.

Sign up for GitHub

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

Jump to bottom

Support preallocated pthread & wasm worker from blob #22565

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Support preallocated pthread & wasm worker from blob #22565

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 14 additions & 4 deletions src/library_pthread.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -98,10 +98,20 @@ var LibraryPThread = {
},
initMainThread() {
#if PTHREAD_POOL_SIZE
var pthreadPoolSize = {{{ PTHREAD_POOL_SIZE }}};
// Start loading up the Worker pool, if requested.
while (pthreadPoolSize--) {
PThread.allocateUnusedWorker();
preallocateWorkers = () => {
var pthreadPoolSize = {{{ PTHREAD_POOL_SIZE }}};
// Start loading up the Worker pool, if requested.
while (pthreadPoolSize--) {
PThread.allocateUnusedWorker();
}
};
#if expectToReceiveOnModule('mainScriptUrlOrBlobPromise')
Copy link
Collaborator

Choose a reason for hiding this comment

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

What is mainScriptUrlOrBlobPromise? I don't see that anywhere in the existing source code? Is the idea that someone could add this to -sINCOMING_JS_MODULE_API? If so I wonder if we should document it somewhere.

If that creation of the main thread needs to be delayed until the mainScriptUrlOrBlob is ready can't this be done via existing mechanisms? For example, any of these approaches:

  1. Using MODULARIZE and delaying the instantiation of the module.
  2. Delaying the import of the emscripten-generated script
  3. Using addRunDependency ? (this one might not work since I'm not sure it blocks initMainThread.

if (Module['mainScriptUrlOrBlobPromise']) {
Module['mainScriptUrlOrBlobPromise'].then(preallocateWorkers);
} else
#endif
{
preallocateWorkers();
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

How about instead updating init() and leaving initMainThread() unchanged.

e.g.:

#if expectToReceiveOnModule('mainScriptUrlOrBlobPromise')
if (Module['mainScriptUrlOrBlobPromise']) Module['mainScriptUrlOrBlobPromise'].then(PThread.initMainThread());
else
#endif
PThread.initMainThread()

This would avoid the new/extra closure.

#endif
#if !MINIMAL_RUNTIME
Expand Down
2 changes: 1 addition & 1 deletion src/library_wasm_worker.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -182,7 +182,7 @@ if (ENVIRONMENT_IS_WASM_WORKER
'mem': wasmMemory,
#else
'wasm': wasmModule,
'js': Module['mainScriptUrlOrBlob'] || _scriptName,
'js': URL.createObjectURL(Module["mainScriptUrlOrBlob"]) || _scriptName,
Copy link
Collaborator

Choose a reason for hiding this comment

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

So this is fix for the case when mainScriptUrlOrBlob is a blob? Is this because blobs cannot be serialized but object URLs can?

Can we add a test for this? And perhaps make it a separate PR and it seems somewhat orthogonal.

'wasmMemory': wasmMemory,
#endif
'sb': stackLowestAddress, // sb = stack bottom (lowest stack address, SP points at this when stack is full)
Expand Down
Loading