readline() blocks after select() says there's data??

[Grant Edwards]

In article <2b57f654.0203151908.33413282 at posting.google.com>, wealthychef wrote:
> "Donn Cave" <donn at u.washington.edu> wrote in message news:<a6tic4$uke$1 at nntp6.u.washington.edu>...
>> Quoth wealthychef at mac.com (wealthychef):
>> ...
>> |> The complementary problem, of course, is that once you have invoked
>> |> readline(), it will read all the data available on the file descriptor,
>> |> or a lot of it anyway, and return only the first line.  The next time,
>> |> it will return the next line from its buffer, but you have no way to
>> |> know that it has another line waiting there.  select() can't see it.
>> |> There are solutions, I think the easiest thing in most cases is to
>> |> throw away the file object and just use the file descriptor (fileno())
>> |> (or sockets in this case.)
>> |
>> | This is even more frightening.  I don't want to lose any data!  How
>> | can I protect myself from this?  Why is using the file descriptor
>> | better?
>> 
>> Well, you're not exactly losing data, it's just buffered, though that
>> may be too fine a point depending on the circumstances.
> 
> Here's what I mean.  If I do a select.select() and it says, "there's
> data," then I do a readline() on the file object, but select() was
> talking about 2 lines of data, I will lose a line of data, because my
> next select() will say "nothing left."  Is that right? 

No.  If there is two lines of data and you only read one, the
second one is still there.  Calling select will return
immediately since there is data ready.

> I just want to be sure I understand this.  You're saying that
> os.read() somehow get what select.select() was talking about, but that
> f.fromchild.readline() will read less than that?

If I understand correctly, the answer is yes.

-- 
Grant Edwards                   grante             Yow!  My mind is a potato
                                  at               field...
                               visi.com