[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/2] copy-file-range: new module
From: |
Pádraig Brady |
Subject: |
Re: [PATCH 1/2] copy-file-range: new module |
Date: |
Fri, 28 Jun 2019 19:56:05 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 07/06/19 09:04, Paul Eggert wrote:
> Although I agree with both of Bruno's reasons, on further thought it makes
> sense
> for Gnulib to provide a stub instead of an emulation for this particular
> function.
>
> The primary use for copy_file_range is to copy files more efficiently than a
> read+write loop. However, the read+write loop will typically still be needed
> anyway, to handle non-regular files, copying across file system boundaries,
> or
> even copying regular input files whose size shrinks while copying as
> copy_file_range (mistakenly, in my view) reports an error if asked to copy
> past
> end of file.
>
> Because of all these special cases, a reliable use of copy_file_ranges will
> need
> to be followed by a read+write loop that handles the special cases where
> copy_file_ranges fails. And this read+write loop will work even if
> copy_file_range is a stub that always fails. So there's no practical need to
> emulate copy_file_range.
>
> For an example of the code I'm thinking of, see the call to copy_file_range
> that
> I recently introduced into GNU Emacs:
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=486a81f387bb59b2fbbc6aff7b41adbe1621394e
>
> Because of the above, I simplified Gnulib's implementation of copy_file_range
> by
> installing the attached. If we find a good use for copy_file_range that could
> take advantage of an emulator rather than a stub, we can revert this.
I definitely agree with this decision.
I also see that yesterday glibc also reverted to a stub rather than emulation:
https://sourceware.org/ml/libc-alpha/2019-06/msg00873.html
cheers,
Pádraig