[silverlyra]

I believe that day has already come: https://nodejs.org/docs/latest-v20.x/api/worker_threads.html...

When you create a Worker with the worker_threads module, Node spawns a new V8 isolate in the same process: https://github.com/nodejs/node/blob/v20.12.1/src/node_worker...

It’s much more isolation than C threads – the entry point for a thread is a whole module (not a function), and threads must use message passing to communicate. They can share memory, but only via [Shared]ArrayBuffer objects. They're in the same OS process, but each have their own global process object.

But I think it'd meet your need for an in-process isolated execution environment, which you can terminate from the main thread after a timeout.

[winrid]

Yes, this is what we do today. Was hoping for something a bit more ergonomic when you don't need full module level isolation.

[kevingadd]

I would be concerned about terminating an isolate on timeout, couldn't it be holding mutexes when you terminate it?

[silverlyra]

If you use SharedArrayBuffers in worker threads, use Atomics.wait to block, and then terminate the worker which would've called Atomics.notify – yes, if no timeout is used on the notify.

But I don't know of any other way this would happen.

[jhgg]

V8 isolate termination is more akin to throwing an uncatchable exception, versus killing a thread abruptly. When you ask v8 to terminate an isolate, it does take some time for it to terminate depending on what code is running.

[billywhizz]

i'm pretty sure node.js does not enable v8 sandboxing by default. https://github.com/nodejs/node/blob/main/deps/v8/BUILD.gn#L3...