You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Tinypool can be used to run tasks in node:worker_threads only. However it seems that various Node ecosystem packages are incompatible with worker_threads, e.g. aws-sdk, @prisma/client, bcrypt. Typically the common feature of these packages is that they utilize NodeJS API's through native addons. I guess there is a reason why Jest does not use worker_threads by default.
Add an option to choose between node:worker_threads and node:child_process runtimes.
Constructor
newTinypool({})// Defaults to 'worker_threads' for backwards compatibilitynewTinypool({runtime: 'worker_threads'})newTinypool({runtime: 'child_process'})
In future we might even add support for third party runtimes. These could be for example browser runtimes:
There might be times where we don't know which runtime to use when initializing the pool. We'll need to add support for changing the runtime of existing pool.
pool.run()
constpool=newTinypool({runtime: 'worker_threads',minThreads: 4,maxThreads: 4})awaitpool.run(task)// Runs in `worker_threads`
At this point pool has 4 idle worker_threads. We want to run next task in child_process instead:
awaitpool.run(task,{runtime: 'child_process'})
Pool notices that runtime does not match with idle workers. It has to pick a worker from pool, terminate it and spawn a new worker with different runtime.
Once task has finished there will be 3 worker_threads and 1 child_process workers idle.
pool.recycleWorkers()
For optimal performance the end-users should be able to change runtime of all workers. This can be useful when they can identify which runtimes their predetermined tasks will need.
consttasks=[...]constpool=newTinypool({runtime: 'worker_threads'})// Run `worker_thread` tasks firstawaitPromise.all(tasks.filter(pickWorkerThreadCompatibleTasks).map(t=>pool.run(t)))awaitpool.recycleWorkers({runtime: 'child_process'})// All idle workers will now be `child_process` runtimesawaitPromise.all(tasks.filter(pickChildProcessTasks).map(t=>pool.run(t)))
Other
This won't be easy task and might require heavy refactoring. If there are some features that require worker_threads, I think we should simply throw or log an error when those are called with different runtime.
Best approach to start this is to create a common interface for runtimes. This interface would hide implementation details of runtimes and provide a simple API for pool to utilize. Same interface would eventually be used by third party runtime implementors.
The text was updated successfully, but these errors were encountered:
Implementing the runtime changing for a single task seems really difficult. Piscina's codebase wasn't built to support this kind of changes.
I think this part of the feature should be left out for now. Users could still change the runtime using pool.recycleWorkers({ runtime }). That one should be much easier to implement.
Description
Currently Tinypool can be used to run tasks in
node:worker_threads
only. However it seems that various Node ecosystem packages are incompatible withworker_threads
, e.g.aws-sdk
,@prisma/client
,bcrypt
. Typically the common feature of these packages is that they utilize NodeJS API's through native addons. I guess there is a reason why Jest does not useworker_threads
by default.Add an option to choose between
node:worker_threads
andnode:child_process
runtimes.Constructor
In future we might even add support for third party runtimes. These could be for example browser runtimes:
Pool methods
There might be times where we don't know which runtime to use when initializing the pool. We'll need to add support for changing the runtime of existing pool.
pool.run()
At this point pool has 4 idle
worker_threads
. We want to run next task inchild_process
instead:Pool notices that runtime does not match with idle workers. It has to pick a worker from pool, terminate it and spawn a new worker with different runtime.
Once task has finished there will be 3
worker_threads
and 1child_process
workers idle.pool.recycleWorkers()
For optimal performance the end-users should be able to change runtime of all workers. This can be useful when they can identify which runtimes their predetermined tasks will need.
Other
This won't be easy task and might require heavy refactoring. If there are some features that require
worker_threads
, I think we should simply throw or log an error when those are called with different runtime.Best approach to start this is to create a common interface for runtimes. This interface would hide implementation details of runtimes and provide a simple API for pool to utilize. Same interface would eventually be used by third party runtime implementors.
The text was updated successfully, but these errors were encountered: