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
