tornado.process — Utilities for multiple processes¶
Utilities for working with multiple processes, including both forking the server into multiple processes and managing subprocesses.
Returns the number of processors on this machine.
- tornado.process.fork_processes(num_processes, max_restarts=100)¶
Starts multiple worker processes.
If num_processes is None or <= 0, we detect the number of cores available on this machine and fork that number of child processes. If num_processes is given and > 0, we fork that specific number of sub-processes.
Since we use processes and not threads, there is no shared memory between any server code.
Note that multiple processes are not compatible with the autoreload module (or the autoreload=True option to tornado.web.Application which defaults to True when debug=True). When using multiple processes, no IOLoops can be created or referenced until after the call to fork_processes.
In each child process, fork_processes returns its task id, a number between 0 and num_processes. Processes that exit abnormally (due to a signal or non-zero exit status) are restarted with the same id (up to max_restarts times). In the parent process, fork_processes returns None if all child processes have exited normally, but will otherwise only exit by throwing an exception.
Returns the current task id, if any.
Returns None if this process was not created by fork_processes.
- class tornado.process.Subprocess(*args, **kwargs)¶
Wraps subprocess.Popen with IOStream support.
The constructor is the same as subprocess.Popen with the following additions:
- stdin, stdout, and stderr may have the value tornado.process.Subprocess.STREAM, which will make the corresponding attribute of the resulting Subprocess a PipeIOStream.
- A new keyword argument io_loop may be used to pass in an IOLoop.
Runs callback when this process exits.
The callback takes one argument, the return code of the process.
This method uses a SIGCHILD handler, which is a global setting and may conflict if you have other libraries trying to handle the same signal. If you are using more than one IOLoop it may be necessary to call Subprocess.initialize first to designate one IOLoop to run the signal handlers.
In many cases a close callback on the stdout or stderr streams can be used as an alternative to an exit callback if the signal handler is causing a problem.
- classmethod initialize(io_loop=None)¶
Initializes the SIGCHILD handler.
The signal handler is run on an IOLoop to avoid locking issues. Note that the IOLoop used for signal handling need not be the same one used by individual Subprocess objects (as long as the IOLoops are each running in separate threads).
- classmethod uninitialize()¶
Removes the SIGCHILD handler.