Select hangs after some reads

[Grant Edwards]

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.

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

I'm lost.

> Of course I can clean the buffer myself, but I think the
> socket module should provide a way of doing this.

I'm afraid I don't understand what you mean.  

Since you talked about calling readline(), I assumed that you
had called the socket object's makefile() method to create a
file-object.  The select system call can only tell you whether
a recv on the socket will block or not.  It knows nothing about
the state of the file object on which you're calling readline().

-- 
Grant Edwards                   grante             Yow!  Is this an out-take
                                  at               from the "BRADY BUNCH"?
                               visi.com