worker: refactor thread life cycle management

The current mechanism of uses two async handles, one owned by the
creator of the worker thread to terminate a running worker,
and another one employed by the worker to interrupt its creator on its
natural termination. The force termination piggybacks on the message-
passing mechanism to inform the worker to quiesce.

Also there are few flags that represent the other thread's state /
request state because certain code path is shared by multiple
control flows, and there are certain code path where the async
handles may not have come to life.

Refactor into an AsyncRequest abstraction that exposes routines to
install a handle as well as to save a state.

PR-URL: https://github.com/nodejs/node/pull/26099
Refs: https://github.com/nodejs/node/pull/21283
Reviewed-By: Anna Henningsen <anna@addaleax.net>

1 files changed, 0 insertions, 16 deletions

diff --git a/src/node_messaging.cc b/src/node_messaging.cc
index 34977557c5b..7ca3ad14d03 100644
--- a/src/node_messaging.cc
+++ b/src/node_messaging.cc
@@ -584,13 +584,6 @@ void MessagePort::OnMessage() {
       // Get the head of the message queue.
       Mutex::ScopedLock lock(data_->mutex_);
 
-      if (stop_event_loop_) {
-        Debug(this, "MessagePort stops loop as requested");
-        CHECK(!data_->receiving_messages_);
-        uv_stop(env()->event_loop());
-        break;
-      }
-
       Debug(this, "MessagePort has message, receiving = %d",
             static_cast<int>(data_->receiving_messages_));
 
@@ -740,15 +733,6 @@ void MessagePort::Stop() {
   data_->receiving_messages_ = false;
 }
 
-void MessagePort::StopEventLoop() {
-  Mutex::ScopedLock lock(data_->mutex_);
-  data_->receiving_messages_ = false;
-  stop_event_loop_ = true;
-
-  Debug(this, "Received StopEventLoop request");
-  TriggerAsync();
-}
-
 void MessagePort::Start(const FunctionCallbackInfo<Value>& args) {
   Environment* env = Environment::GetCurrent(args);
   MessagePort* port;