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

src: dispose of V8 platform in process.exit() #25061

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
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
7 changes: 5 additions & 2 deletions src/env.cc
Original file line number Diff line number Diff line change
Expand Up @@ -857,10 +857,13 @@ void Environment::AsyncHooks::grow_async_ids_stack() {
uv_key_t Environment::thread_local_env = {};

void Environment::Exit(int exit_code) {
if (is_main_thread())
if (is_main_thread()) {
stop_sub_worker_contexts();
Copy link
Member

Choose a reason for hiding this comment

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

I was reviewing this method and its callee chains, and have this doubt:

  • Worker::Exit | Isolate::TerminateExecution - are these callable from another thread? Of course, it is possible to do so, and any thread is able to modify the data structures pertinent to a worker - but we are doing nothing to stop the execution of the thread that is represented by this worker? In other words, how / at what point are we physically stopping the worker thread?

Copy link
Member Author

Choose a reason for hiding this comment

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

Worker::Exit | Isolate::TerminateExecution - are these callable from another thread?

Yes, they are essentially worker.terminate() – in particular, Isolate::TerminateExecution() is one of the few thread-safe V8 functions.

In other words, how / at what point are we physically stopping the worker thread?

We’re stopping the event loop and disallowing JS execution, waiting for everything to finish and then join the thread … as far as I could tell, that’s the best we can do here.

I guess this might be problematic when some threads have environment cleanup handlers registered via addons that block indefinitely? That would not really be a bug on our side, though…

DisposePlatform();
exit(exit_code);
else
} else {
worker_context_->Exit(exit_code);
}
}

void Environment::stop_sub_worker_contexts() {
Expand Down
4 changes: 4 additions & 0 deletions src/node.cc
Original file line number Diff line number Diff line change
Expand Up @@ -340,6 +340,10 @@ tracing::AgentWriterHandle* GetTracingAgentWriter() {
return v8_platform.GetTracingAgentWriter();
}

void DisposePlatform() {
v8_platform.Dispose();
}

#ifdef __POSIX__
static const unsigned kMaxSignal = 32;
#endif
Expand Down
1 change: 1 addition & 0 deletions src/node_internals.h
Original file line number Diff line number Diff line change
Expand Up @@ -357,6 +357,7 @@ int ThreadPoolWork::CancelWork() {
}

tracing::AgentWriterHandle* GetTracingAgentWriter();
void DisposePlatform();

static inline const char* errno_string(int errorno) {
#define ERRNO_CASE(e) case e: return #e;
Expand Down