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 15:02:35 +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> <20130604084128 dot GB19572 at calimero dot vinschen dot de>
- Reply-to: cygwin at cygwin dot com
On Jun 4 10:41, Corinna Vinschen wrote:
> 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
> 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.
Despite the Windows shortcomings outlined in my other mail, I created
this patch. It enables mandatory locking for flock and lockf. The way
to enable it is still the F_LCK_MANDATORY flag.
I uploaded a new 32 bit snapshot 2013-06-04 and a 1.7.19-10 64 bit tesst
release. Please test.
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