Guido van Rossum wrote:
To distinguish a timeout error, the caller can check s->sock_timeout when a non-blocking mode error occured, or just return an error code from internal_select() (I guess you must have your reason to taken it out in the first place)
I don't understand your first suggestion. Not all errors mean that the timeout triggered!
For example, when accept() fail with error code EAGAIN and s->sock_timeout = 5.0, it indicates timeout. Same for connect() fail with EINPROGRESS. Anyway, on second thought, it is messy.
How about the following (assume we have socket.setDefaultTimeout()):
import socket import urllib socket.setDefaultTimeout(5.0) retry = 0 url = 'some url' while retry < 3: try: file = urllib.urlretrieve(url) except socket.TimeoutError: if retry == 2: print "Server too busy, given up!" raise else: print "Server busy, retry!" retry += 1 else: break
MS IIS behave strangely to http request. When the server is very busy, it will randomly drop some requests without disconnecting the client. So the best approach for the client is to timeout and retry. I guess that might be the reason why people needed timeoutsocket in the first place.
One of the reasons (there are lots of reasons why a connect or receive attempt may be very slow to time out, or even never time out).
Of course, this stll doesn't distinguish between a timeout from connect() and one from recv().
I think you are right on the point. Client might not care if the call is timeouted on connect() or recv(). In this case a timeout error comes handy.
Have you ever written code like this?
Yes I did.
I am struggling with the test case for the new socket code. The timeout test case I've send you works with the old socketmodule.c (attached), but not with the lastest version (on linux or windows). It's strange, your new implementation looks much cleaner.
No need to attach copies of old versions -- just give me the CVS revision number. :-)
socketmodule.c version 1.225 socketmodule.h version 1.7
Please bear with me a bit longer for a patch :.(
Anyway, I have no time to play with this right now, so I'm glad you aren't giving up just yet. :-)
It is very painful indeed (Tim was so right).
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)