This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Promote sqlite 3.7.13-1 from test status?


On 8/16/2012 2:50 AM, Corinna Vinschen wrote:
On Aug 16 07:41, Achim Gratz wrote:
there's a race
somewhere between calls from the Cygwin DLL and Windows file locking functions.

Cygwin does not use Windows mandatory locking. The locking is entirely implemented within the Cygwin DLL and is only advisory, as is befitting for a POSIX envionment.

Interesting. I never knew that. I'd assumed that since Cygwin occasionally gets tangled up with Windows mandatory locking (e.g. in-use DLL replacement) that it was playing by those rules all the time.


If you try to use the same file with a
non-Cygwin tool using Windows locking in parallel with a Cygwin tool,
you will get into trouble.  The mandatory Windows locking will always
win and the Cygwin tool will fail.

I think that nails the problem.


SQLite has a lot of Windows and Cygwin specific code in it, and in large part, it treats Cygwin as "Windows", including use of the Win32 API LockFile(). (See osLockFile() and winLock*() in sqlite3.c.)

When you force it to build in "Unix mode", all that code gets ifdef'd out, replaced by an entirely different set of OS-specific I/O wrappers, such as unixLock().

So, what you did with that requested change, Achim, is prevented Cygwin svn from winning any fights over ownership of .svn/wc.db.

This could have happened to anything built against Cygwin SQLite, where there is also another native Windows program trying to access the same DB file. The only Subversion-specific thing about this problem was how Subversion was coded to react when it happened. Another program might not say "disk I/O error," but would somehow fail nevertheless.

Reverting this change put Cygwin SQLite based programs back on an even footing with native SQLite based programs.

I gotta say, I'm not wild about the way SQLite treats Cygwin as Windows, bypassing the POSIX APIs so often. Yet, you can see the logic, at least in the case of file locking. Mandatory file locking is a very good thing in the case of SQLite.

Anyway, I'm going to update my RFU request to promote 3.7.13-1 to curr.

Thanks all for the responses. It's helped clear things up for me.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]