Issue976613
Created on 2004-06-21 09:36 by astrand, last changed 2009-02-16 01:33 by movement.
| File name |
Uploaded |
Description |
Edit |
Remove |
|
socketmodule.patch
|
astrand,
2004-06-21 09:37
|
Suggested patch 1 |
|
|
|
msg21231 - (view) |
Author: Peter Åstrand (astrand) |
Date: 2004-06-21 09:36 |
|
The timeout stuff in the socket module does not work
correctly on Solaris. Here's a typical example:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(("localhost", 9048))
s.listen(1)
s.settimeout(10)
conn, addr = s.accept()
print 'Connected by', addr
while 1:
data = conn.recv(1024)
if not data: break
conn.send(data)
conn.close()
When connecting, I get this traceback:
Connected by ('127.0.0.1', 32866)
Traceback (most recent call last):
File "foo.py", line 10, in ?
data = conn.recv(1024)
socket.error: (11, 'Resource temporarily unavailable')
This is because Python treats the new socket object as
blocking (the timeout value is -1). However, in
Solaris, sockets returned from accept() inherits the
blocking property. So, because the listenting socket
was in non-blocking mode, the new connected socket will
be non-blocking as well. Since the timeout is -1,
internal_select will not call select.
The solution to this problem is to explicitly set the
blocking mode on new socket objects. The attached patch
implements this.
|
|
msg21232 - (view) |
Author: Peter Åstrand (astrand) |
Date: 2004-06-21 12:20 |
|
Logged In: YES
user_id=344921
One workaround for this problem is:
socket.setdefaulttimeout(somethinglarge)
Or, if you have the possibility, you can do
conn.setblocking(1) right after accept().
|
|
| Date |
User |
Action |
Args |
| 2009-02-16 01:33:29 | movement | set | nosy:
+ movement |
| 2009-02-14 14:47:02 | ajaksu2 | set | stage: test needed type: behavior components:
+ Extension Modules versions:
+ Python 2.6, - Python 2.3 |
| 2008-01-05 14:15:42 | vila | set | nosy:
+ vila |
| 2004-06-21 09:36:13 | astrand | create | |
|