A library to pool Node.js worker threads, automatically exposing exported module methods using Proxy Objects for easy bi-directional communication between main and worker thread.
+ Full TypeScript Support (optionally using ts-node in development)
+ Only one dependency (the debug package)
+ Callbacks (workers can call back functions on the main thread)
+ Graceful Shutdown (drains the pool and terminates)
npm install thread-puddle
# or
yarn add thread-puddle// examples/ts-class/worker.ts
export class MyWorker {
say(): void {
console.log('Hello!')
}
}
export default new MyWorker()// examples/ts-class/main.ts
import { createThreadPool } from '../../lib'
import { MyWorker } from './worker'
(async () => {
const worker = await createThreadPool<MyWorker>('./worker')
await worker.say() // -> "Hello!"
worker.pool.terminate()
})()This and more examples can be found in the examples directory.
createThreadPool uses TypeScript generics and other advanced features to give you the type of how your worker module will actually be exposed to the main thread.
TL;DR: The captured type for your thread will be modified to only return async methods and be extended with the pool interface.
Example:
interface Calculations {
crunchNumbers(data: number[]): number;
}
// Using as worker type:
const worker = createThreadPool<Calculations>('./calc-worker')
// Will basically become:
interface Calculations {
crunchNumbers(data: number[]): Promise<number>;
pool: PoolInterface
}Creates a pool of workers and waits until all workers are ready to call methods on, then returns a Proxy Object which will forward method calls to the worker.
Arguments:
workerPath- an absolute or relative path to a module.options- optional settings:size- the number of worker threads to be created in the pool for the given module. Defaults to1.workerOptions- will be used as options for the worker thread constructor. Defaults to{}.startupTimeout- if a worker thread cannot be started within this timout in milliseconds, the pool creation will fail and reject with a timout error. Defaults to30000.typecheck- In developmentts-nodeis used, which by default runstranspile-onlymode. To get type checks, set this totrue.maxQueueSize- When filled up with waiting calls, will reject all subsequent calls, until emptied to below max again. Defaults to1000autoRefill- Automatically fills up the pool with workers untilsizeis reached when workers unexpectedly exit. Defaults tofalse.
If the pool size is > 1, method calls will be forwarded to the next available worker. If all workers are busy, the method calls will be queued. A worker will handle one method call at any time only.
On the Proxy Object returned from createThreadPool, you can call any method which is exported from the workerPath module. All method calls are async and return a Promise, no matter if the module method is async or not. The promise will be resolved with the return value of the method in the worker module. If the method call fails in the worker thread, the Promise will be rejected with that error and the original stack trace. If a method is not available on the worker, the Promise will be rejected with an error.
method- Must match a method name exported from the worker module.arguments- Arbitrary number of arguments forwarded to the method call in the worker thread.
Arguments are transferred to the worker thread via postMessage, compatible with the HTML structured clone algorithm. If you want to move arguments of type ArrayBuffer or MessageChannel instead of copying them, you can use the withTransfer helper.
Arguments can contain a function (callback) in the first level, which will be callable from the thread via a reference, but be executed on the main thread.
However, the result of the callback is currently not transfered back to the thread. It is possible to implement a worker thread with an EventEmitter though, see the eventemitter example. Callback errors will throw an unhandled exception if no error listener is attached to the pool callback:error event like worker.pool.on('callback:error', () => ...).
// examples/ts-callbacks/worker.ts
export class MyWorker {
callMe(callback: (msg: string) => void): void {
callback('Hello!')
}
}
export default new MyWorker()// examples/ts-callbacks/main.ts
import { createThreadPool } from '../../lib'
import { MyWorker } from './worker'
async function start () {
const worker = await createThreadPool<MyWorker>('./worker')
const callback = (msg: string) => console.log(msg)
await worker.callMe(callback)
worker.pool.terminate()
}
start()Will call the given method on all workers, as soon as they become available. Returns a list of the results from all workers, like Promise.all. Otherwise behaves the same as worker.[method]([arguments]).
Terminates the pool and all worker threads in it. Trying to call methods in the pool afterwards, will result in an rejection.
Fills up the pool with workers until size is reached. Can be used to manually decide wether to refill or terminate.
Waits until all calls are handled and threads are idle, then terminates all threads.
The number of worker threads in the pool.
Wether or not the pool was terminated.
This helper can be used bi-directional, to transfer values to a worker thread as method call argument(s), or to transfer return values from a worker thread method.
Arguments:
value- Any value which contains transferrables (ArrayBufferorMessageChannel).transferList- Ifvalueitself is not a typed array, the list may specify any transferrable contained invalue.
Example method arguments:
// Main thread
const buf = Buffer.from('my main buffer value')
const value = {
buf,
anotherValue: true
}
worker.customMethod(withTransfer(value, [buf])) // <--Example return value:
// Worker thread
module.exports = {
customMethod() {
const buf = Buffer.from('my thread buffer value')
const value = {
buf,
anotherValue: true
}
return withTransfer(value, [buf]) // <--
}
}Forwards errors that are emitted for a specific worker in the pool. When a worker thread errors, it is terminated. The pool will spawn another worker, unless it is terminated.
Forwards exit events that are emitted for a specific worker in the pool, adding the threadId as second argument.
Thread Puddle has only one dependency: debug
Namespaces:
puddle:*- all debug logs for the modulepuddle:master- only logs from the pool controllerpuddle:thread:*- logs for all threads onlypuddle:thread:[id]- logs for a specific thread
Nested Namespaces:
puddle:parent:[id]:masterpuddle:parent:[id]:thread:[id]
The debug method with the correct namespace is exported from the thread-puddle entry point.
© 2022 Sebastian Herrlinger
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.