[Twisted-Python] _Win32Waker
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
On Thu, 5 Mar 2009 16:49:15 -0600, Aron Bierbaum <aronbierbaum@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
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:
On Thu, 5 Mar 2009 16:49:15 -0600, Aron Bierbaum <aronbierbaum@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
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, 9 Mar 2009 09:17:14 -0500, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
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?
Not really, sorry. I know that behavior often differs subtly or grossly from Windows machine to Windows machine, but not why. Jean-Paul
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:
On Mon, 9 Mar 2009 09:17:14 -0500, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
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?
Not really, sorry. I know that behavior often differs subtly or grossly from Windows machine to Windows machine, but not why.
Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, 20 Apr 2009 18:16:39 -0500, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
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.
Hmm. Interesting. Perhaps we could bind a different port, then. I look forward to results from your further investigations. Jean-Paul
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:
On Mon, 20 Apr 2009 18:16:39 -0500, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
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.
Hmm. Interesting. Perhaps we could bind a different port, then. I look forward to results from your further investigations.
Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Sorry, forgot to attach the C++ example. -Aron On Tue, Apr 21, 2009 at 2:22 PM, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
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:
On Mon, 20 Apr 2009 18:16:39 -0500, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
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.
Hmm. Interesting. Perhaps we could bind a different port, then. I look forward to results from your further investigations.
Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
participants (2)
-
Aron Bierbaum -
Jean-Paul Calderone