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: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)


On Jun  3 17:58, David Rothenberger wrote:
> On 6/3/2013 1:11 PM, Warren Young wrote:
> > This is a big-push attempt at a version of Cygwin SQLite that will make
> > everyone happy (ha!) whether they want POSIX advisory locking behavior
> > or Windows mandatory locking behavior.  My part of the effort is being
> > stubborn on this point and doing the basic testing and packaging.  The
> > real magic was added by Corinna to yesterday's 1.7.19 cygwin1.dll snapshot.
> 
> Thank you (and thank you Corinna!) for all your hard work and
> perseverance with this issue.
> 
> Unfortunately...
> 
> > - By default, it requests mandatory locking using the feature added in
> > yesterday's Cygwin 1.7.19 snapshot.  This should make it cooperate with
> > native Windows programs also using SQLite despite running in Unix mode.
> > 
> > - This mandatory-locks-by-default feature of this SQLite build can be
> > disabled by setting the new CYGWIN_SQLITE_LOCKING environment variable
> > to "posix".
> 
> ... initial results with the Subversion test suite (for 1.8.0-rc2) show
> that most tests fail with a "sqlite: database is locked (S5)" error
> unless CYGWIN_SQLITE_LOCKING=posix.

The question now is: Why?  The problem here is that the semantics of
POSIX locks and Windows locks is so very different.  I guess that
sqlite, when build in POSIX mode, (rightfully) assumes that the POSIX
locks behave like POSIX locks and so uses them accordingly.  This
collides with the way Windows locks work.

If so, mandatory locking via fcntl locks is pretty much useless in this
scenario.  The application using it has to know that the semantics are
different and so create another code path which respects the annoying
Windows lock behaviour (like the fact that a write lock blocks another
write lock even if both are requested by the same process using the same
HANDLE).

A potential workaround is to use BSD flock locks in sqlite.  Given that
they lock the entire file, the behaviour is not so prone to the problems
of Windows locks.
It's easy enough to add that to Cygwin, so I'll do that within the hour.
That requires another sqlite test release, obviouly.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 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


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