This is the mail archive of the
mailing list for the Cygwin project.
Re: pread vs. git
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 17 Jul 2012 10:05:32 +0200
- Subject: Re: pread vs. git
- References: <5004EF52.firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
On Jul 16 22:51, Eric Blake wrote:
> Recent git added a hack to explicitly avoid cygwin's pread as unsafe:
Boy, is that annoying. Cygwin's pread/pwrite is thread-safe since June
2011. The implementation isn't optimal, but at least the thread-safety
is ensured by the current implementation. What version of Cygwin is
that guy using?
> Comments like this aren't very re-assuring either:
This mail refers to a temporary patch which has been overridden by
the current implementation, described by the below comment.
> or this big hairy comment in the source of fhandle_disk_file:
> Using this handle for pread/pwrite would break atomicity, because the
> read/write operation would have to be followed by a seek back to the old
> file position. What we do is to open another handle to the file on the
> first call to either pread or pwrite. This is used for any subsequent
> pread/pwrite. Thus the current file position of the "normal" file
> handle is not touched.
> Note that this is just a hack. The problem with this approach is that
> a change to the file permissions might disallow to open the file with
> the required permissions to read or write. This appears to be a border case,
> but that's exactly what git does. It creates the file for reading and
> writing and after writing it, it chmods the file to read-only. Then it
> calls pread on the file to examine the content. This works, but if git
> would use the original handle to pwrite to the file, it would be broken
> with our approach.
> One way to implement this is to open the pread/pwrite handle right at
> file open time. We would simply maintain two handles, which wouldn't
> be much of a problem given how we do that for other fhandler types as
> However, ultimately fhandler_disk_file should become a derived class of
> fhandler_base_overlapped. Each raw_read or raw_write would fetch the
> actual file position, read/write from there, and then set the file
> position again. Fortunately, while the file position is not maintained
> by the I/O manager, it can be fetched and set to a new value by all
> processes holding a handle to that file object. Pread and pwrite differ
> from raw_read and raw_write just by not touching the current file pos.
> What still remains to make pread a first-class thread-safe
> implementation that obeys POSIX, so that I don't have to cripple my next
> build of git to avoid threaded pread?
The fix this comment refers to was specificially created to make git work.
It is thread-safe. The downside of the current implementation is exactly
described, but is no problem for current git since it does *not* use the
original handle to call pwrite. What's also described is how to fix this
problem once and for all. http://cygwin.com/acronyms/#SHTDI
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple