[Top][All Lists]

[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:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]