This is the mail archive of the
mailing list for the Cygwin project.
Re: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 4 Jun 2013 10:41:28 +0200
- Subject: Re: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)
- References: <51ACF886 dot 10301 at etr-usa dot com> <51AD3BB4 dot 2010601 at acm dot org>
- Reply-to: cygwin at cygwin dot com
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.
> > - 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
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 Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple