[TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)
Corinna Vinschen
corinna-cygwin@cygwin.com
Tue Jun 4 13:02:00 GMT 2013
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
> 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.
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.
Thanks,
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
More information about the Cygwin
mailing list