On Jan 18 16:24, Christopher Faylor wrote: > On Fri, Jan 18, 2013 at 04:10:25PM -0500, Christopher Faylor wrote: > >On Sat, Jan 19, 2013 at 12:18:39AM +0400, Andrey Repin wrote: > >>Greetings, Corinna Vinschen! > >> > >>>> 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. > >> > >>That made me think... If rtorrent uses MS_ASYNC, shouldn't *rtorrent* be > >>prepared for consequences? Instead of you trying to satisfy its > >>expectations?
Me adding MS_SYNC handling has nothing to do with the original problem. It was just something I realized being missing in our msync implementation while looking into the rtorrent behaviour. Actually, what I was really looking into at this time was... > >It does seem that way. > > Actually, it isn't that clear. It seems like msync is failing in the > MS_ASYNC case when it shouldn't be, i.e., rtorrent is within its rights > to expect the operation to succeed. ...this: Under Linux, msync might return with errno set to EBUSY if "MS_INVALIDATE was specified in flags, and a memory lock exists for the specified address range."(*) This sounds a lot like what rtorrent occurs. So, what I was looking for is if rtorrent calls msync with the MS_INVALIDATE flag, but it doesn't. Right now the msync loop does not handle MS_INVALIDATE specificially, only after the loop is exited is EBUSY returned now. OTOH, usually the kernel is not expected to lock a memory page temporarily for its own dubious purposes *and* let a user mode function call fail due to that. Corinna (*) http://www.kernel.org/doc/man-pages/online/pages/man2/msync.2.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
