[Python-Dev] Minor socket timeout quibble - timeout raises socket.error

[Guido van Rossum]

> > 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/)