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

[Grant Edwards]

On 2007-08-24, Hendrik van Rooyen <mail at microcorp.co.za> wrote:
> "Grant Edwards" <gr....com> wrote:
>
>> On 2007-08-23, Hendrik van Rooyen <m....ocorp.co.za> 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
close().

>> > 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...

Yes.

> 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?
                                  at               
                               visi.com