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.
+ 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 @armit/worker-threads
# or
yarn add @armit/worker-threads
// 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-node
is used, which by default runstranspile-only
mode. 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 to1000
-
autoRefill
- Automatically fills up the pool with workers untilsize
is 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 (ArrayBuffer
orMessageChannel
). -
transferList
- Ifvalue
itself 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.
Worker Threads has only one dependency: debug
Namespaces:
-
armit-worker:*
- all debug logs for the module -
armit-worker:master
- only logs from the pool controller -
armit-worker:thread:*
- logs for all threads only -
armit-worker:thread:[id]
- logs for a specific thread
Nested Namespaces:
armit-worker:parent:[id]:master
armit-worker:parent:[id]:thread:[id]
The debug method with the correct namespace is exported from the thread-puddle
entry point.