Node Worker pthreads pool reuse

[kripken]

#9745 supports Node Workers and the pthread pool works properly, but the pool elements are not reused. For example,

https://github.com/emscripten-core/emscripten/blob/incoming/tests/pthread/test_pthread_create.cpp

creates many many threads and destroys them (so at every point in time only a small amount exist). This hangs on node as after exhausting the pool, we have no more workers to use.

I think the issue is that pthread_exit in workers actually exits the entire Worker in node. We call the node process API to do that, as it's better than throwing an exception - which on the Web halts the worker but leaves the application alone, but in Node brings down the whole thing. So I guess we need to find a way to do what we do on the Web, in Node.

[dschuff]

Or just do what native thread libraries do, i.e. actually create a new thread. I'll bet it's a lot cheaper in Node than it is on the web.

[sbc100]

I agree. Lets just not do the pool thing on node. Creating a pool of threads in userspace is possible if people what to do that (which is also common in the non-web world).

[kripken]

The problem is that creating the pool is a workaround for the issue of expecting a thread to immediately be usable. That is, creating a thread is an async operation, so the main thread needs to return to the event loop and wait.

[sbc100]

But is that true with node as well? Don't we have synchronous primitives under node?

[kripken]

It seems to still be true in Node.js, yes, creating a Worker doesn't make it immediately available, the event loop must be returned to. I don't see an API to synchronously create and run a Worker. But maybe I missed something, cc @addaleax

[addaleax]

I don't see an API to synchronously create and run a Worker. But maybe I missed something, cc @addaleax

There’s nothing built-in, but if you want something like this, you could pass an Int32Array over a SharedArrayBuffer in the workerData option to the Worker constructor, and use Atomics.wait() on the main thread and Atomics.notify() once you want to wake up the main thread from that wait call. (I’d be curious why you need the thread to be immediately usable in that case, though.)

I think the issue is that pthread_exit in workers actually exits the entire Worker in node. We call the node process API to do that, as it's better than throwing an exception - which on the Web halts the worker but leaves the application alone, but in Node brings down the whole thing. So I guess we need to find a way to do what we do on the Web, in Node.

You can still throw an exception if that’s what you want. If you want it to not bring down the Worker entirely, you can attach a process.on('uncaughtException', ...) listener inside of the Worker thread.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.