> On Fri, Aug 11, 2017 at 6:46 AM Victor Stinner <victor.stin...@gmail.com>
>> => 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:
>> 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
>> 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 <r...@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.
Python-Dev mailing list