Socket recv(1) seems to block instead of returning end of file.

Grant Edwards grante at
Fri Aug 24 17:30:01 CEST 2007

On 2007-08-24, Hendrik van Rooyen <mail at> wrote:
> "Grant Edwards" <> wrote:
>> On 2007-08-23, Hendrik van Rooyen <> wrote:
>> > While doing a netstring implementation I noticed that if you
>> > build a record up using socket's recv(1), then when you close
>> > the remote end down, the recv(1) hangs,
>> I don't see that behavior running 2.4 on Gentoo.
> I express myself badly - when I say "close down" I don't mean
> "close down as in socket.close" I mean "close down as in click on the
> tkinter window, or with keyboard interrupt" - sorry for the confusion

A FIN is a FIN is a FIN.  It shouldn't matter whether the app
called close() or the c library called close() or the OS called

>> > despite having a short time out of 0.1 set.
>> What time out?  A socket's recv method doesn't do timeouts.
> If I set a time out, then the recv does not block,
> but gives me a timed out exception.

My aplogies -- my question was prompted by my ignorance of the
fact that a timeout feature had been added to the socket module
since the last time I worked on it.

> I am now frustrated - its not as simple as I thought - my
> application still only detects EOF if I do more than recv(1),
> but I cannot demonstrate simply - anyway, I have modified your
> code to look more like my program's code, and it follows below
> - if it does nothing else, it should convince you that recv()
> *does* time out...


> The receiver code below detects if I close the sending console window, 
> as well as control-c - Rats!

Same here.

Grant Edwards                   grante             Yow! Am I having fun yet?

More information about the Python-list mailing list