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

[Bernard Yue]

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  :.(
> 
> OK.
> 
> 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/~guido/)

Bernie