On Fri, Aug 11, 2017 at 6:46 AM Victor Stinner <victor.stinner@gmail.com> wrote:
=> http://bugs.python.org/issue31151
I changed the code to call waitpid() in blocking mode on each child process on server_close(), to ensure that all children completed when on server close:
https://github.com/python/cpython/commit/aa8ec34ad52bb3b274ce91169e1bc4a5986...
After pushing my change, I'm not sure anymore if it's a good idea. There is a risk that server_close() 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@lab.net> wrote:
Since ThreadingMixIn also leaks threads, server_close() 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.