Date: Mon, 7 Mar 2011 11:38:49 -0500
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.8: write fails with EAGAIN
Message-ID: <20110307163849.GA26824@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4D72992D DOT 4090007 AT tweerlei DOT de> <20110307103951 DOT GL6393 AT calimero DOT vinschen DOT de> <20110307153708 DOT GA2538 AT ednor DOT casa DOT cgf DOT cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110307153708.GA2538@ednor.casa.cgf.cx>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Mon, Mar 07, 2011 at 10:37:08AM -0500, Christopher Faylor wrote:
>On Mon, Mar 07, 2011 at 11:39:51AM +0100, Corinna Vinschen wrote:
>>On Mar  5 21:12, Robert Wruck wrote:
>>> Hi,
>>> 
>>> recently, I found that cygwin-git was not able to 'cat-file' files
>>> that exceeded some size (in my case about 80MB).
>>> I tracked this down to the cygwin implementation of write() that
>>> behaves quite odd in some cases.
>>> 
>>> I wrote a small program (source attached) that mmaps a given file
>>> and tries to write it to another file or stdout.
>>> 
>>> The results vary:
>>> 
>>> If the destination is a file (`writetest infile outfile` or
>>> `writetest infile > outfile`), the write succeeds in a single call.
>>> 
>>> If the destination is a pipe (`writetest infile | cat > outfile`),
>>> the write succeeds in most cases. BUT:
>>> 
>>> Under WinXP (XP Service Pack 2, 32bit), the call returns -1 and
>>> errno=EAGAIN. Nevertheless, SOME data is written to the pipe (in my
>>> case 4096 byte for each call).
>>> This breaks git since it does an infinite loop while errno=EAGAIN.
>>
>>Hang on, you are saying that a *blocking* write(2) to a pipe returns
>>with EAGAIN?  Are you sure?  It would be quite a surprise if git would
>>actually do that.  EAGAIN is only an expected error for non-blocking
>>I/O, so applications which use blocking I/O usually only test for EINTR.
>
>I can barely convince myself that there's a pathological case where an
>EAGAIN could leak out.  I'm investigating now.

Actually, in this case, it looks like the problem is that Windows
doesn't like sending a huge buffer to a pipe.  The errno in this case
should probably be something like EFBIG rather than EAGAIN.

Does git deal with this type of errno gracefully or does it just abort
if the write() fails for any reason?  I'd rather just fail and let the
caller deal with it than complicate Cygwin's code by trying to loop
writing smaller amount of data to the pipe so I'd prefer just changing
the errno if that solves the problem.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple