A single instance of Node runs in a single thread. To take advantage of multi-core systems the user will sometimes want to launch a cluster of Node processes to handle the load. The cluster module allows you to easily create child processes that all share server ports.
This feature was introduced recently, and may change in future versions. Please try it out and provide feedback.
Also note that, on Windows, it is not yet possible to set up a named pipe server in a worker.
Static variables
Variables
read onlyisMaster:Bool
True if the process is a master.
This is determined by the process.env.NODE_UNIQUE_ID.
If process.env.NODE_UNIQUE_ID is undefined, then isMaster is true.
schedulingPolicy:ClusterSchedulingPolicy
The scheduling policy, either SCHED_RR for round-robin
or SCHED_NONE to leave it to the operating system.
This is a global setting and effectively frozen once you spawn the first worker
or call setupMaster, whatever comes first.
SCHED_RR is the default on all operating systems except Windows.
Windows will change to SCHED_RR once libuv is able to effectively distribute IOCP handles
without incurring a large performance hit.
schedulingPolicy can also be set through the NODE_CLUSTER_SCHED_POLICY environment variable.
Valid values are "rr" and "none".
read onlysettings:ClusterSettings
After calling setupMaster (or fork) this settings object will contain the settings, including the default values.
It is effectively frozen after being set, because setupMaster can only be called once.
This object is not supposed to be changed or set manually, by you.
read onlyworker:Worker
A reference to the current worker object.
Not available in the master process.
read onlyworkers:DynamicAccess<Worker>
A hash that stores the active worker objects, keyed by id field.
Makes it easy to loop through all the workers.
It is only available in the master process.
A worker is removed from workers just before the 'disconnect' or 'exit' event is emitted.
Should you wish to reference a worker over a communication channel, using the worker's unique id
is the easiest way to find the worker.
Methods
disconnect(?callback:() ‑> Void):Void
Calls disconnect on each worker in workers.
When they are disconnected all internal handles will be closed, allowing the master process to die gracefully if no other event is waiting.
The method takes an optional callback argument which will be called when finished.
This can only be called from the master process.
fork(?env:DynamicAccess<String>):Worker
Spawn a new worker process.
This can only be called from the master process.
setupMaster(?settings:{silent:Null<Bool>, exec:Null<String>, args:Null<Array<String>>}):Void
setupMaster is used to change the default fork behavior.
Once called, the settings will be present in settings.
Note that:
Only the first call to `setupMaster` has any effect, subsequent calls are ignored
That because of the above, the only attribute of a worker that may be customized per-worker
is the `env` passed to `fork`
`fork` calls `setupMaster` internally to establish the defaults, so to have any effect,
`setupMaster` must be called before any calls to `fork`