Select hangs after some reads

[Steve Holden]

alsmeirelles at gmail.com wrote:
> Grant Edwards escreveu:
> 
> 
>>On 2006-06-08, alsmeirelles at gmail.com <alsmeirelles at gmail.com> wrote:
>>
>>
>>>Well, actually I´m using a very simple protocol wich sends only
>>>strings ended by newline. I need to send 3 chunks of information and a
>>>newline after them. On the reader side I make 3 readline(), this way I
>>>wouldn´t have to care about this problem, but maybe that´s where I´m
>>>falling. If that´s the case, I´ll have to use a more complex
>>>protocol.
>>
>>You can't use readline() with select().  Select tells you
>>whether recv() called on the underlying socket will block or
>>not.  What's probably happening is that all of the data has
>>been read from the underlying socket and is being held in a
>>buffer waiting to be read by readline().
>>
> 
> 
> Yes, as I expected, its the buffers. In my opinion the problem is that
> the socket module
> doesn't provide a way of reading all its internal buffer.
> 
> readlines() just make subsequent calls to readline and readline may
> call recv, so we have a locked scene. I want to know if I will block
> anyway. Of course I can clean the buffer myself, but I think the socket
> module should provide a way of doing this. It's not a big problem
> though.
> 
> 
> 
>>The Select call has no way of knowing about that buffered data.
>>As far as it's concerned there's no more data left to read, so
>>it block until the socket is closed.
> 
> 
> You're very right.
> thanks,
> 
Of course, if the client forces the TCP PSH flag true then the receiver 
is guaranteed to debuffer the stream up to that point - this is how FTP 
clients work, for example.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Love me, love my blog  http://holdenweb.blogspot.com
Recent Ramblings     http://del.icio.us/steve.holden