This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: SocketServer.ForkingMixIn.collect_children() waits on pid 0
Type: behavior Stage:
Components: Library (Lib) Versions: Python 2.6, Python 2.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Ringding, gvanrossum, jyasskin, nnorwitz, schmir
Priority: normal Keywords:

Created on 2006-08-15 04:48 by nnorwitz, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (6)
msg60970 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-08-15 04:48
SocketServer.ForkingMixIn.collect_children() does:

       pid, status = os.waitpid(0, options)

By setting pid = 0, it will wait on any children, even
if the children were not started by the SocketServer. 
This causes sporadic test failures:

It later assumes that if any child finished, that this
server owned the process, which is not a valid
assumption.  Any part of the code could have spawned
the child.

I will fix the test suite, so this problem shouldn't
occur (well at least reduce the likelihood by reaping
the children before each test).

I'm not certain how this problem should really be fixed
(or if it's even worth fixing).  Two possible solutions
 * only wait on the children we own
 * ignore returned pids that we don't own
msg60971 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2006-08-15 04:49
Logged In: YES 

I forgot to mention that this problem seems to have
sporadically hit many of the buildbots.  Though it seemed to
always occur on cygwin.
msg60972 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2006-08-15 15:06
Logged In: YES 

It should keep track of the pids of all its children and
only wait for those.  Shouldn't be hard.  Can be done in
2.5.1 since it's a bugfix.
msg63099 - (view) Author: Jeffrey Yasskin (jyasskin) * (Python committer) Date: 2008-02-28 18:05
Mostly fixed in r61106. This should make the buildbots happy, but there
is still a corner case in which we waitpid(0) and could confuse other
msg86358 - (view) Author: Stefan Ring (Ringding) Date: 2009-04-23 09:17
Jeffrey, this very commit broke it. See also issue 5814. The same
happened for me last week. What makes it especially bad is that even
once enough children terminate, the SocketServer won't be able to handle
any more connections; it just throws this Exception again and again and
closes new connections immediately.
msg86368 - (view) Author: Jeffrey Yasskin (jyasskin) * (Python committer) Date: 2009-04-23 14:53
Yes, sorry. That was fixed in r69927.
Date User Action Args
2022-04-11 14:56:19adminsetgithub: 43822
2010-08-03 20:12:20terry.reedysetstatus: open -> closed
resolution: fixed
2009-04-23 14:53:42jyasskinsetmessages: + msg86368
2009-04-23 09:17:44Ringdingsetnosy: + Ringding
messages: + msg86358
2008-03-14 19:52:37schmirsetnosy: + schmir
2008-02-28 18:05:02jyasskinsetnosy: + jyasskin
type: behavior
messages: + msg63099
versions: + Python 2.6
2006-08-15 04:48:13nnorwitzcreate