[Twisted-Python] _Win32Waker
![](https://secure.gravatar.com/avatar/a60aec004390fa723770ff571aa20b2d.jpg?s=120&d=mm&r=g)
I have been using a custom Qt4 reactor that derives from PosixReactorBase. As a result it creates a _Win32Waker to allow threads and signals to wake up the IO thread. It seems though that the current implementation only works about half of the time. The other half it exists with : File "...\Lib\python2.6\site-packages\twisted\internet\posixbase.py", line 170, in __init__ ReactorBase.__init__(self) File "...\Lib\python2.6\site-packages\twisted\internet\base.py", line 424, in __init__ self._initThreads() File "...\Lib\python2.6\site-packages\twisted\internet\base.py", line 813, in _initThreads self.installWaker() File "...\Lib\python2.6\site-packages\twisted\internet\posixbase.py", line 206, in installWaker self.waker = _Waker(self) File "...\Lib\python2.6\site-packages\twisted\internet\posixbase.py", line 77, in __init__ client.connect(server.getsockname()) File "<string>", line 1, in connect socket.error: [Errno 10049] The requested address is not valid in its context I have attached a simple test that shows that the following code does not always return "127.0.0.1", but sometimes returns "0.0.0.0" as the IP address. # Following select_trigger (from asyncore)'s example; server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.setsockopt(socket.IPPROTO_TCP, 1, 1) server.bind(('127.0.0.1', 0)) server.listen(1) client.connect(server.getsockname()) My current workaround just calls the following instead: client.connect(('127.0.0.1', server.getsockname()[1])) Any ideas on what is really causing the error? If there is not a better solution can this be added to trunk for future releases? Thanks, Aron
![](https://secure.gravatar.com/avatar/7ed9784cbb1ba1ef75454034b3a8e6a1.jpg?s=120&d=mm&r=g)
On Thu, 5 Mar 2009 16:49:15 -0600, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
It's definitely true that you can't connect to "0.0.0.0" on Windows, and various parts of Twisted try to deal with this in some way already. It isn't clear to me why that getsockname() isn't returning "127.0.0.1" though. I expect it's due to some configuration change or third-party networking software on the Windows machine. Do you think you can track that down? That will make it much easier to think about the problem and the solution. Jean-Paul
![](https://secure.gravatar.com/avatar/a60aec004390fa723770ff571aa20b2d.jpg?s=120&d=mm&r=g)
I have been unable to reproduce this problem on multiple machines that I have tested on. Also I have tried changing various network settings on my machine without any change. Do you have any ideas what I should be looking for? Thanks, Aron On Fri, Mar 6, 2009 at 7:51 AM, Jean-Paul Calderone <exarkun@divmod.com> wrote:
![](https://secure.gravatar.com/avatar/a60aec004390fa723770ff571aa20b2d.jpg?s=120&d=mm&r=g)
I have looked into this a little more and have noticed that if I specify a port number instead of "0" it will always bind to the correct "127.0.0.1" address. I still don't know why this only occurs on certain Windows machines. I will hopefully get more time to look into this in the next couple of days. -Aron On Mon, Mar 9, 2009 at 9:36 AM, Jean-Paul Calderone <exarkun@divmod.com> wrote:
![](https://secure.gravatar.com/avatar/a60aec004390fa723770ff571aa20b2d.jpg?s=120&d=mm&r=g)
I have been able to reproduce the same results with a simple C++ example. I have been unable to find any specific reason why binding to "127.0.0.1" and later calling getsockname would result in a different address of "0.0.0.0" I did find one reference [1] that said that using a port number of 0 will cause the operating system to listen on all interfaces and that calling getsockname may not return a valid address until the socket is fully connected. It might be best to use the original patch that I sumbitted that only uses the port value from the getsockname call, and uses the correct "127.0.0.1" IP address regardless of the reported address. If the address returned is really undefined, then this could be causing the problem. -Aron [1] http://www.sockets.com/winsock.htm#Bind [2] Change the following line in posixbase.py client.connect(server.getsockname()) to client.connect(('127.0.0.1', server.getsockname()[1])) On Mon, Apr 20, 2009 at 7:06 PM, Jean-Paul Calderone <exarkun@divmod.com> wrote:
![](https://secure.gravatar.com/avatar/7ed9784cbb1ba1ef75454034b3a8e6a1.jpg?s=120&d=mm&r=g)
On Thu, 5 Mar 2009 16:49:15 -0600, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
It's definitely true that you can't connect to "0.0.0.0" on Windows, and various parts of Twisted try to deal with this in some way already. It isn't clear to me why that getsockname() isn't returning "127.0.0.1" though. I expect it's due to some configuration change or third-party networking software on the Windows machine. Do you think you can track that down? That will make it much easier to think about the problem and the solution. Jean-Paul
![](https://secure.gravatar.com/avatar/a60aec004390fa723770ff571aa20b2d.jpg?s=120&d=mm&r=g)
I have been unable to reproduce this problem on multiple machines that I have tested on. Also I have tried changing various network settings on my machine without any change. Do you have any ideas what I should be looking for? Thanks, Aron On Fri, Mar 6, 2009 at 7:51 AM, Jean-Paul Calderone <exarkun@divmod.com> wrote:
![](https://secure.gravatar.com/avatar/a60aec004390fa723770ff571aa20b2d.jpg?s=120&d=mm&r=g)
I have looked into this a little more and have noticed that if I specify a port number instead of "0" it will always bind to the correct "127.0.0.1" address. I still don't know why this only occurs on certain Windows machines. I will hopefully get more time to look into this in the next couple of days. -Aron On Mon, Mar 9, 2009 at 9:36 AM, Jean-Paul Calderone <exarkun@divmod.com> wrote:
![](https://secure.gravatar.com/avatar/a60aec004390fa723770ff571aa20b2d.jpg?s=120&d=mm&r=g)
I have been able to reproduce the same results with a simple C++ example. I have been unable to find any specific reason why binding to "127.0.0.1" and later calling getsockname would result in a different address of "0.0.0.0" I did find one reference [1] that said that using a port number of 0 will cause the operating system to listen on all interfaces and that calling getsockname may not return a valid address until the socket is fully connected. It might be best to use the original patch that I sumbitted that only uses the port value from the getsockname call, and uses the correct "127.0.0.1" IP address regardless of the reported address. If the address returned is really undefined, then this could be causing the problem. -Aron [1] http://www.sockets.com/winsock.htm#Bind [2] Change the following line in posixbase.py client.connect(server.getsockname()) to client.connect(('127.0.0.1', server.getsockname()[1])) On Mon, Apr 20, 2009 at 7:06 PM, Jean-Paul Calderone <exarkun@divmod.com> wrote:
participants (2)
-
Aron Bierbaum
-
Jean-Paul Calderone