Repository navigation
Node SEA with useSnapshot cannot start worker thread #56077
Copy link
Copy link
Closed
Labels
single-executableIssues and PRs related to single-executable applications.Issues and PRs related to single-executable applications.snapshotIssues and PRs related to the startup snapshot.Issues and PRs related to the startup snapshot.
Description
Activity
This also breaks the esm loader hooks because it also runs in a thread.
Looks like here:
Lines 322 to 350 in 03ec900
| #ifndef DISABLE_SINGLE_EXECUTABLE_APPLICATION | |
| if (sea::IsSingleExecutable()) { | |
| sea::SeaResource sea = sea::FindSingleExecutableResource(); | |
| // The SEA preparation blob building process should already enforce this, | |
| // this check is just here to guard against the unlikely case where | |
| // the SEA preparation blob has been manually modified by someone. | |
| CHECK_IMPLIES(sea.use_snapshot(), | |
| !env->snapshot_deserialize_main().IsEmpty()); | |
| } | |
| #endif | |
| // Ignore env file if we're in watch mode. | |
| // Without it env is not updated when restarting child process. | |
| // Child process has --watch flag removed, so it will load the file. | |
| if (env->options()->has_env_file_string && !env->options()->watch_mode) { | |
| per_process::dotenv_file.SetEnvironment(env); | |
| } | |
| // TODO(joyeecheung): move these conditions into JS land and let the | |
| // deserialize main function take precedence. For workers, we need to | |
| // move the pre-execution part into a different file that can be | |
| // reused when dealing with user-defined main functions. | |
| if (!env->snapshot_deserialize_main().IsEmpty()) { | |
| return env->RunSnapshotDeserializeMain(); | |
| } | |
| if (env->worker_context() != nullptr) { | |
| return StartExecution(env, "internal/main/worker_thread"); | |
| } |
added on Dec 2, 2024
single-executableIssues and PRs related to single-executable applications.Issues and PRs related to single-executable applications.
Hmm, looks like we just need to skip the SEA stuff for worker threads during bootstrap, since that's meant for the main thread anyway.
Reacted by Yanlong Wang
added on Dec 3, 2024
snapshotIssues and PRs related to the startup snapshot.Issues and PRs related to the startup snapshot.
added a commit that references this issue on Dec 7, 2024
added a commit that references this issue on Dec 10, 2024
added a commit that references this issue on Dec 20, 2024
added a commit that references this issue on Jan 5, 2025
Metadata
Metadata
Assignees
Labels
single-executableIssues and PRs related to single-executable applications.Issues and PRs related to single-executable applications.snapshotIssues and PRs related to the startup snapshot.Issues and PRs related to the startup snapshot.
Version
v22.11.0
Platform
Subsystem
sea
What steps will reproduce the bug?
Generate a SEA and start a worker thread in it
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior? Why is that the expected behavior?
Thread can be started.
What do you see instead?
Native stack trace
Additional information