GeezerVison

Description

Supersedes #2068 with a different approach to the same two crashes.

Race on worker shutdown. RunMainThreadEntry read a worker's isolate from the callback cache, released cacheMutex_, and only then took a v8::Locker on it. A worker shutting down in that window (DestroyRuntime → Dispose) freed the isolate first, and the main thread crashed in v8::Locker::Initialize.

#2068 fixed this by making the worker wait for in-flight main-thread holds before disposing. That keeps the isolate alive for a caller that will then only find its entry gone: the main thread still locks and enters a worker that was told to terminate, and teardown waits on main-thread progress. This PR drops the call instead:

• Each worker owns an IsolateGate (std::mutex + open), held by shared_ptr in the cache entry so it outlives the isolate.
• The main thread takes the gate's mutex, returns if the gate is closed, and releases it only once it owns the worker's Locker.
• Worker shutdown closes the gate before it takes its teardown Locker, while holding no Locker. Once closed, the main thread never touches the isolate. The worker never waits for the main thread beyond the Locker contention that already existed.
• The gate is per worker and never taken while holding that worker's Locker, so there is no lock-order cycle. A global mutex would deadlock against a worker that calls __runOnMainThread while holding its own Locker.

Main-isolate entries (multithreaded JS) carry no gate and are unchanged.

Throwing worker callbacks. Under uncaughtErrorPolicy: "throw", a worker callback's uncaught error was rethrown on the main thread as a Java exception. That exception resolved a handle from the worker isolate against the main one and crashed (SIGSEGV in NativeScriptException::ReThrowToJava). Worse, it would have taken the app down for an error that belongs to the worker. It now goes through the worker's own error path (CallWorkerScopeOnErrorHandle: the worker's onerror, then the parent's Worker object), as the worker's message dispatch already does. Under the default report policy nothing changes.

Does your commit message include the wording below to reference a specific issue in this repo?

No issue; supersedes #2068.

Related Pull Requests

• fix(worker): keep a worker isolate alive while a __runOnMainThread callback locks it #2068 (superseded)

Does your pull request have unit tests?

No new spec. The race window is a few instructions wide, and the throw policy can't run in the device suite because it crashes the app on purpose (see testUncaughtErrorPolicy.js). Verified manually with a focused repro on an arm64 API 35 emulator, with usleep(200000) injected in RunMainThreadEntry right after the entry lookup:

The full device suite passes (runtestsAndVerifyResults: 1545/1545, on top of #2067, #2069 and #2070).

Summary by CodeRabbit

• Bug Fixes
  • Worker callbacks are now safely discarded when a worker is shutting down, preventing them from running against a disposed runtime.
  • Uncaught exceptions from worker callbacks now follow the worker’s error-handling path instead of being raised as Java exceptions on the main thread. Callbacks from the main runtime retain their existing exception behavior.