X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 18 Jan 2013 17:07:42 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: rtorrent and recent snapshots - apparent problem with msync()
Message-ID: <20130118160742.GH11791@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CAGHJv4fiyojmQGR_d4=Pv1q9dtJogbcfCKBj_LtWyYsLYOFBGQ AT mail DOT gmail DOT com> <20130117062415 DOT GB24529 AT ednor DOT casa DOT cgf DOT cx> <CAGHJv4cTsRD5km3oSmBy2BbWGTvL2mfbU9xRMPbnj2XCLN7HgQ AT mail DOT gmail DOT com> <CAGHJv4cAm+v_VuKXxjdriTN-d-AoQfengNEFY+MqZOAnOsH0-Q AT mail DOT gmail DOT com> <20130118003522 DOT GA1913 AT ednor DOT casa DOT cgf DOT cx> <20130118093205 DOT GB11791 AT calimero DOT vinschen DOT de> <20130118154352 DOT GA23471 AT ednor DOT casa DOT cgf DOT cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20130118154352.GA23471@ednor.casa.cgf.cx>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Jan 18 10:43, Christopher Faylor wrote:
> On Fri, Jan 18, 2013 at 10:32:05AM +0100, Corinna Vinschen wrote:
> >On Jan 17 19:35, Christopher Faylor wrote:
> >> And, Corinna, please if the change I made to your function is wrong or
> >> you just don't like my variable names or comments please feel free to
> >> expunge what I did with extreme prejudice.
> >
> >Looks good to me.  I'm just wondering.  I have a similar piece of code
> >in the rename function in syscalls.cc, lines 2342ff.  This loop also
> >allows signals to break the loop.  Maybe we should do the same here?
> >
> >I just read the Linux msync man page(*) as well as the MSDN
> >FlushViewOfFile man page(**).  Looks like this function is missing a
> >bit of functionality.  Right now msync only calls FlushViewOfFile.
> >Per MSDN this is equivalent to msync called with the MS_ASYNC flag.
> >If the MS_SYNC flag is given, the function should also call FlushFileBuffers.
> >I'll fix that.
> >
> >Also, Linux msync is allowed to return with EBUSY if "MS_INVALIDATE was
> >specified in flags, and a memory lock exists for the specified address
> >range."  That seems to match our situation... except that rtorrent
> >doesn't use the MS_INVALIDATE flag.  Either way, maybe we should
> >translate ERROR_LOCK_VIOLATION to EBUSY?
> >
> >(*)  http://www.kernel.org/doc/man-pages/online/pages/man2/msync.2.html
> >(**) http://msdn.microsoft.com/en-us/library/windows/desktop/aa366563%28v=vs.85%29.aspx
> 
> That sounds right to me.  EACCES didn't seem like the right translation
> here.

Ok, I'll fix that in errno.cc.

> >> I can't explain what in the newer snapshots would cause a difference
> >> in behavior other than the fact that they were being built with a
> >> newer compiler and a revamped configure script.
> >
> >I tried with my gcc 4.5.3 build and I can't reproduce the problem.
> >Still, it's just calls to OS functions.  There should be no compiler
> >induced difference in the error values returned from OS functions.
> >Except your gcc produces faster code than WIndows allows ;)
> 
> Yeah, my compiler setup is great.  Now if I could just use it to compile
> my packages, I'd be very happy.  So far it only seems to work right with
> Cygwin.  Other stuff, like gdb and binutils are currently problematic.

Current binutils CVS HEAD doesn't build on Cygwin(*).  The 2.23.1
version should work, though.

> I saw that you made another change to this function.  Is it possible that
> this might actually fix the "rtorrent problem"?

No.  It only adds the MS_SYNC handling.  rtorrent uses MS_ASYNC.
I think there's basically no way around the loop.  I'm just still
wondering if we shouldn't add a cygwait() call to handle signals
during the wait time.


Corinna

(*) http://sourceware.org/ml/binutils/2013-01/msg00303.html

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

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