[Twisted-Python] _Win32Waker

[Jean-Paul Calderone]

On Thu, 5 Mar 2009 16:49:15 -0600, Aron Bierbaum <aronbierbaum at gmail.com> wrote:
>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?

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