socket's strange behavior with subprocesses
cbrown at metservice.com
Wed Nov 12 20:43:22 CET 2003
"Jane Austine" <janeaustine50 at hotmail.com> wrote in message
news:ba1e306f.0311120837.6e6eddf2 at posting.google.com...
> Running Python 2.3 on Win XP
> It seems like socket is working interdependently with subprocesses of
> the process which created socket.
> and the server side tries to close the socket:
> Alas, the client side doesn't wake up! It doesn't wake up unless the
> notepad is exited first; only after that, 'Connection reset by peer'
> is raised. What does the socket has to do with subprocesses?
I think it may be tied up with the way subprocesses are made under Windows.
Below is a copy of part of a post I made some months back when inexplicable
file-locking was causing me problems. It took me weeks to track down the
The Python default subprocess inherits open handles from the parent.
Your options are:
1. Open the subprocess before the socket.
2. Create the subprocess using win32 API primitives (this is what I had to
Let me know if want details.
I have been struggling to solve why an occasional "Permission Denied" error
popped up from the following code fragment in one of my Win2K program
input_file = preprocess(raw_file)
os.system('third_party input_file output_file > error_file')
The error occurs on the os.rename(). The third_party executable was closing
input_file before terminating and anyway the subshell process has finished
before the os.rename is called! Most baffling.
With the aid of handle.exe from www.sysinternals.com I finally resolved the
problem. To see the problem at first hand try the following script:
import time, thread, os
print 'delete x.x'
if os.name == 'nt':
elif os.name == 'posix':
print 'end wait'
print 'create x.x'
f = open('x.x','w')
print '\nclose x.x'
Although this works fine on Linux, I get a Permission Denied error on
Windows. I surmise that an os.system call uses a C fork to create the
subshell - an exact duplicate of the current process environment including
OPEN FILE HANDLES. Because the os.system call has not returned before the
os.remove is called a "Permission Denied" error occurs. Quite simple really.
Now going back to my original problem, I had other threads doing os.system
calls. When one of these calls happens during the preprocess file write of
my above thread AND takes longer to complete than the os.system call in the
above thread then the file will still be open and the os.rename will return
the Permission Denied error.
More information about the Python-list