Opened 8 years ago
Last modified 8 years ago
"openSocketServer.py" and "openSocketsChild.py" are the simple example in the documentation for the module "socket" in the standard library. If you run them, they work as expected: the server listens, the client connects, the server sends some data and disconnects, the client received the data, print and quit. "openSocketSpawner.py" is meant to be run with "twistd -r win32 -noy openSocketSpawner.py" and all it does it spawning a subprocess that runs "openSocketChild.py" and grabs the output. But the child dies without being able to open a socket: X:\>twistd -r win32 -noy openSocketSpawner.py 2004/12/23 16:28 ora solare Europa occidentale [-] Log opened. 2004/12/23 16:28 ora solare Europa occidentale [-] twistd 1.3.0 (C:\Python23\python.exe 2.3.4) starting up 2004/12/23 16:28 ora solare Europa occidentale [-] reactor class: twisted.internet.win32eventreactor.Win32Reactor 2004/12/23 16:28 ora solare Europa occidentale [-] connectionMade! 2004/12/23 16:28 ora solare Europa occidentale [-] processEnded, status 1 2004/12/23 16:28 ora solare Europa occidentale [-] quitting 2004/12/23 16:28 ora solare Europa occidentale [-] Traceback (most recent call last): 2004/12/23 16:28 ora solare Europa occidentale [-] File "openSocketChild.py", line 7, in ? 2004/12/23 16:28 ora solare Europa occidentale [-] s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 2004/12/23 16:28 ora solare Europa occidentale [-] File "C:\Python23\lib\socket.py", line 154, in __init__ 2004/12/23 16:28 ora solare Europa occidentale [-] _sock = _realsocket(family, type, proto) 2004/12/23 16:28 ora solare Europa occidentale [-] socket.error: (10106, 'winsock error') 2004/12/23 16:28 ora solare Europa occidentale [-] 2004/12/23 16:28 ora solare Europa occidentale [-] Main loop terminated. 2004/12/23 16:28 ora solare Europa occidentale [-] Server Shut Down.
You need to explicitly grant permission to spawned processes on win32?
For some reason the process is not able to open a socket. Something must be wrong (I don't know much about win32).
Upgrading for 2.0
For 2.0, we should implement something simple with threads and popen3(). It doesn't matter how inefficient or wasteful the implementation is, it should just implement the interface and work reliably (especially with respect to argument handling and process termination). We can continue trying to implement real process support for windows post 2.0. The simple implementation of this should be pretty easy. Any windows developers want to volunteer to work on this?
Of course before we go reimplementing the whole world 2 days before a release we should find out whether this actually is a bug or not and whether a reimplementation using popen instead of win32 API calls actually would even fix the bug.
The error, 10106, is WSAEPROVIDERFAILEDINIT. It can be triggered by not having a proper SystemRoot environment variable set. Not sure why, but I assume it has something to do with loading DLLs. The fix I suggest is modifying win32reactor.Process to include the parent environment by default, rather than including a blank environment. Given how infrequently the environment is even used in win32, I do not believe this constitutes a security hazard, however, I can, if prompted, try verify that comment.
Committed hagbard's suggested fix at r13184.