Johannes Stezenbach wrote:
>>
>>+ /* We may not block here if there are some bytes available in the
>>+ buffer - poll() may have informed the client about that!
>>+ Note that EWOULDBLOCK will never be returned in that case. */
>>+ if (src->pwrite != src->pread)
>>+ non_blocking = 1;
>>+
>> while (todo>0) {
>> if (non_blocking && (src->pwrite==src->pread))
>> return (count-todo) ? (count-todo) : -EWOULDBLOCK;
>
>
> The patch is not correct, but isn't really wrong either ;-/
>
> The question is: Why is there a while (todo>0) loop? My guess
> is that this is a performance optimization as it probably results
> in fewer read() calls. But I'm not convinced that it gives any
> substantial improvement, as programs that use O_NONBLOCK seem
I don't observe performance degradation when working with O_NONBLOCK
either. However, I guess this may be different on really slow machines.
> to work fine (e.g. VDR). Your patch is just an obfuscated version
> of removing the loop.
Yes and no...
Having relatively fast reading thread there's usually no data collected
and read() will wait in the loop until the buffer is filled.
> So if we want to restore "read() after POLLIN won't block" semantics
> we need to drop the loop.
>
> Or we can document the "read() after POLLIN can block unless you use
> O_NONBLOCK" behaviour.
I'd suggest not going that way.
KM
>
> Please cast your vote.
>
>
> Johannes
>
>
