On Fri, Jul 1, 2022 at 1:35 PM Evgeny Kotkov
<evgeny.kot...@visualsvn.com> wrote:
>
> Yann Ylavic <ylavic....@gmail.com> writes:
>
> > Why would buffered reads always be full reads (i.e. until the given
> > size of EOF)?
> >
> > For apr_file_read() I don't think this is expected, users might want
> > read() to return what is there when it's there (i.e. they handle short
> > reads by themselves), so implicit full reads will force them to use
> > small buffers artificially and they'll lose in throughput. On the
> > other hand, users that want full reads can do that already/currently
> > in their own code (by calling read() multiple times).
> >
> > For apr_file_gets() this is the same issue, why when some read returns
> > the \n would we need to continue reading to fill the buffer? In a pipe
> > scenario the peer would apr_file_write("Hello\n") and the consumer's
> > apr_file_read() would not return that to the user immediately?
> >
> > This has nothing to do with buffered vs non-buffered IMHO, there are
> > apr_file_{read,write}_full() already for that.
>
> One comment I have here is that this commit does not change the existing
> behavior of apr_file_read() for buffered files. The read_buffered() helper
> isn't new by itself, as it has been merely factored out from apr_file_read().
>
> So, doing full reads for buffered files has been the current behavior
> for both unix and win32 and for a long time, I think. For example, see
> unix/readwrite.c:file_read_buffered(). This applies to the unix version
> of apr_file_gets() as well.
Oh, and the loop seems to have been removed later in r1828509
"apr_file_read: Optimize large reads from buffered files on Windows"
(backported to 2.4.x in r1902379 too).
So Windows is doing the right thing now (not unix), right?
Sorry for the noise, and thanks for the fix/info :)
Regards;
Yann.
