-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
process, tcpserver: Soft-deprecate multi-process mode #2801
Comments
I'd love to see an example of how |
|
Can you make an example using the
|
Just add |
oh I see. I wanted that parent process (main application) starts with |
|
This uses the soft-deprecated multiprocessing mode of Tornado. Later versions will switch away from it. Ref: tornadoweb/tornado#2801
Is it ok if we install a SIGTERM handler in the parent process to explicitly kill the child process on exit? We are seeing this problem #1912 in our space and looking for possible solutions. Want to ensure this wouldn't cause leaks or other possible conflicts |
Installing a SIGTERM handler in the parent process won't hurt anything, but it's an imperfect solution to orphaned processes as seen in #1912. SIGTERM is not the only reason a process can exit; you could also add handlers for SIGINT and others but you can't have a handler for SIGKILL. A complete solution would need to be in the child processes, either polling |
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
This is partially a casualty of the Python 3.10 deprecation changes, although it's also something I've wanted to do for other reasons, since it's been a very common source of user confusion. Fixes tornadoweb#2801
Multi-process mode has a lot of subtleties; it is responsible for a large fraction of our questions on stack overflow. And now that we have SO_REUSEPORT, I see little reason to use it instead of multiple independent processes (I've always viewed multiple independent processes as desirable for "serious" production use, but the need for an external load balancer is a significant operational overhead that justifies the shared-listener multiprocess mode. But if you can share a port without fork and its associates subtlety, that's even better)
We should at least update the docs to steer people towards reusing ports instead of forking multiple-processes. We might want to go as far as deprecating the process argument to
server.start()
, although I'm in no rush to actually remove it (I don't think I'd deprecate theprocess.fork_processes()
function - empirically the people who get in trouble with multi-process mode are all usingstart(N)
; explicit forking is much more explicit and either the people who try it are able to get it working without difficulty or no one's trying it).The text was updated successfully, but these errors were encountered: