Feature: Single-CPU/no-Worker mode about piscina HOT 10 CLOSED

I’ve thought about it a bit and I’d say I’m reluctant to implement this. There are subtle differences between letting code run on another thread and running it on the same thread, and I don’t like things that work most of the time but sometimes break. :)

For example, we would probably not be able to get rid of the postMessage() calls because the value serialization/deserialization steps affect data layout, and in the most extreme case, anything that uses Atomics.wait()/Atomics.notify() would break pretty badly (i.e. by silently deadlocking).

I think spawning a single separate thread makes sense, even if there is only one CPU.

from piscina.

I'm not sure it's a great idea. Using multithreading allows to keep processing things in the background and keep the event loop healthy / responsive to external requests.

from piscina.

Entirely possible. If those buffers are not being exposed to users, then using a SharedArrayBuffer makes sense, I think. For any Buffer that is exposed to users, I would still marshall

from piscina.

Yes, but it should degrade gracefully in the off chance there is only a single core. It's certainly not ideal and I think the recommendation would be not to use piscina if you know for certain you're on a single core system (there are better solutions) but if that can't be known in advance then an internal no-thread mode would likely be good.

from piscina.

I don't see any in the case of a long CPU-bound task. Without threads, the event loop is going to be blocked.

from piscina.

@mcollina... what behavior would you expect to be reasonable if a user creates a Piscina instance on a single core machine?

from piscina.

I would expect to use a thread that competes for CPU time with the current one. The OS will guarantee both threads a fair share of CPU, so none of them would block. If we run the task on the main thread and it's CPU-bound, it will block the event loop.

from piscina.

Whatcha think @addaleax ? I'm happy with @mcollina's point but want to make sure you are before closing this.

from piscina.

@mcollina That still incurs the IPC overhead, but your point about even loop blocking is valid.

Perhaps I am just doing too much IPC by marshalling buffers instead of using SharedArrayBuffer and the transferList argument. The latter do not incur as much performance penalty, do they?

from piscina.

Think we've got consensus then! Closing!

from piscina.