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.
> > [...]
> > ... 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?

IOW: It would be nice to have a simple testcase (plain C, only Cygwin
POSIX calls, self-contained, yada yada) to see what sqlite expects in
POSIX lock mode.

> 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.

As for "potential": If sqlite tries to convert an existing flock lock
into another type (read lock <-> write lock), this, too, will fail with
Windows locks underneath.  Windows locks require that the existing lock
is unlocked first.

Which gives me an idea.  What if each call to F_SETLK{W} first calls
NtUnlockFile on the given offset and length parameters?  This would
allow overwriting locks held by the same descriptor.  This should at
least help the flock case and often even in the fcntl case.  The fcntl
case which is not solvable is splitting and merging of existing locks.

[...time passes...]

On the other hand, this is non-atomic.  What could happen then is that a
flock call unlocks the existing lock, a task switch occurs, another
process locks the file successfully, and the flock call fails with an
unlocked file (LOCK_NB), or waits until further notice.  And then the
application might not find what it's expecting.

That's SO sick.


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