[Python-Dev] socketserver ForkingMixin waiting for child processes (original) (raw)

Martin Panter vadmium+py at gmail.com
Sat Aug 12 09:07:30 EDT 2017

On Fri, Aug 11, 2017 at 6:46 AM Victor Stinner <victor.stinner at gmail.com> wrote:

=> http://bugs.python.org/issue31151

I changed the code to call waitpid() in blocking mode on each child process on serverclose(), to ensure that all children completed when on server close: https://github.com/python/cpython/commit/aa8ec34ad52bb3b274ce91169e1bc4a598655049 After pushing my change, I'm not sure anymore if it's a good idea. There is a risk that serverclose() blocks if a child is stuck on a socket recv() or send() for some reasons.

I agree that this could be an unwanted change in behaviour. For example, a web browser could be holding a HTTP 1.1 persistent connection open.

Should we relax the code by waiting a few seconds (problem: hardcoded timeouts are always a bad idea), or terminate processes (SIGKILL on UNIX) if they don't complete fast enough?

It does seem reasonable to have an option to clean up background forks, whether by blocking, or terminating them immediately.

On 11 August 2017 at 22:34, Ryan Smith-Roberts <rmsr at lab.net> wrote:

Since ThreadingMixIn also leaks threads, serverclose() could grow a timeout flag (following the socket module timeout convention) and maybe a terminate boolean. ThreadingMixIn could then also be fixed.

You could do a blocking join on each background thread. But I suspect there is no perfect way to terminate the threads without waiting. Using ThreadingMixIn.daemon_threads and exiting the interpreter might have to be good enough.

More information about the Python-Dev mailing list