Re: Socket recv(1) seems to block instead of returning end of file.
- From: Dan Stromberg - Datallegro <dstromberg@xxxxxxxxxxxxxx>
- Date: Thu, 23 Aug 2007 09:48:53 -0700
On Thu, 23 Aug 2007 11:54:01 +0200, 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, despite having a short
time out of 0.1 set.
If however, you try to receive more than one char, (I tested with 3,
did not try 2), then when you shut the remote end down you do not
get a time out, but an empty string - the normal end of file, I suppose.
Has anybody else seen this behaviour?
The transmit side seems to give a broken pipe error, which is fine.
I am using stock standard SuSe 10, Python 2.4, out of the box.
- Hendrik
Are you using sock.settimeout()?
I've always done timed-out sockets in python using select; IINM, the
settimeout method is a new addition.
I agree with Grant though - posting a minimal snippet of code that
replicates the problem would help us help you. In fact, it might help you
help yourself :)
.
- Follow-Ups:
- Re: Socket recv(1) seems to block instead of returning end of file.
- From: Hendrik van Rooyen
- Re: Socket recv(1) seems to block instead of returning end of file.
- From: Grant Edwards
- Re: Socket recv(1) seems to block instead of returning end of file.
- From: Grant Edwards
- Re: Socket recv(1) seems to block instead of returning end of file.
- References:
- Socket recv(1) seems to block instead of returning end of file.
- From: Hendrik van Rooyen
- Socket recv(1) seems to block instead of returning end of file.
- Prev by Date: Re: Python submodules and name imports
- Next by Date: Re: C# and Python
- Previous by thread: Re: Socket recv(1) seems to block instead of returning end of file.
- Next by thread: Re: Socket recv(1) seems to block instead of returning end of file.
- Index(es):
Relevant Pages
|