On Windows, when a suprocess.Popen command is issued while
a socket connection is being handled the socket connection
will not close until the output of the subprocess is consumed.
The connection remains open even though the request.close()
command returns successfully and the program starts listening
for the next connection.

On Windows, the request.close() call translates to the C function
closesocket. The closesocket function by default attempts to do
a graceful close in the background. By changing the linger structure,
the closesocket function can be made to do a hard close. That fixes
my problem, but then queued data may not be flushed before the
socket closes. I cannot figure out why the closesocket's graceful
shutdown is waiting for the Popen command to complete.

This problem does not show up with the equivalent os.popen command.

To reproduce:
    run socketTest.py
    use telnet to connect on port 6288
    watch for connection to close or not

I found a workaround for this issue (attached) via the kernel32.dll
function SetHandleInformation. You can patch the socket class to set all
newly created sockets as uninheritable.

It's not perfect--another thread could still spawn a subprocess in
between.  We probably need some kind of API for setting socket inheritance.

> It's not perfect--another thread could still spawn a subprocess in
> between

Then it could be done in socketmodule.c, when still holding the GIL.
Python code can change back the socket to inheritable afterwards if it
wants to.

> We probably need some kind of API for setting socket inheritance.

Right.