Jeethu Rao jeethur at
Wed Feb 12 22:20:35 CET 2003

> I had code like that recently with an HTTPServer that would block in a
> call
> to handle_request().  My shutdown function would set the flag, then do
> HTTP GET to its own port to force the call to handle_request() to
> There's a race condition here -- if someone else connects to the
> between you setting the flag and connecting yourself, the socket won't
> there when you try.  Even if it is there, connecting like this often
> tosses
> all kinds of errors you'll have to trap (or at least it did in my
> peer
> resets, etc. as a result of the proverbial rug being pulled out from
> underneath it).

Do you mean to say that the connect() from the shutdown function would
Since the server is already dead (because of the external connect)?
That's not really a problem to me, because I'm using timeout sockets.
If it gets to be too long, it just times out (I didn't show that in the 
code for the sake of simplicity)

> That's pretty much how I'd done it before, but it felt hackish and
> inelegant.  Instead, I played with for the first time,
> it's incredibly small.  The following code is based on HTTPServer and
> handle_request() call, but it's essentially the same model as using
> accept().

I personally, find the select method a little hackish, and that's why I
Timeout sockets. timeoutsocket wraps the nitty-gritty details into a
shim. internally uses the same select mechanism you use.

Your overloading the join() method is pretty appealing to me, and sounds
lot More logical than nomenclature: shutdown for the same method.

Jeethu Rao

More information about the Python-list mailing list