> > The way I restructured the code it is impossible to distinguish a > > timeout error from other errors; you simply get the "no data > > available" error from the socket operation. This is the same error > > you'd get in non-blocking mode. > > > > 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! I took it out because it is much less code this way. > > Before I recomplicate the code so that it can raise a separate error > > when the select fails, I'd like to understand the use case better. > > Why would you want to make this distinction? Requeueing the request > > (as in Skip's example) doesn't make sense IMO: you set the timeout for > > a reason, and that reason is that you want to give up if it takes too > > long. If you really intend to retry you're better of disabling the > > timeout! > > > > 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(). Have you ever written code like this? > > If you really want to, you can already distinguish the timeout case, > > because you get an EAGAIN error then (maybe something else on Windows > > -- Bernard, if you have a fix for that, please send it to me). > > 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. :-) > Please bear with me a bit longer for a patch :.( OK. Anyway, I have no time to play with this right now, so I'm glad you aren't giving up just yet. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4