Re: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)

[Corinna Vinschen <corinna-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
> 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