pread vs. git

Corinna Vinschen
Tue Jul 17 08:06:00 GMT 2012

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.
>    FIXME:
>    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
>    well.
>    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.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list