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: Warren Young <warren at etr-usa dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 05 Jun 2013 13:50:38 -0600
- 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>
On 6/4/2013 02:41, Corinna Vinschen wrote:
On Jun 3 17:58, David Rothenberger wrote:
... 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
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.
This is certainly true. We may well end up deciding that, ugly as it
is, the Win32-specific code in SQLite's unhacked Cygwin build actually
makes sense after all, insofar as it encodes the correct way to do
locking on Windows *for SQLite*.
If that ends up being the case, I may be able to exploit SQLite's VFS
fallback mechanism to get a SQLite build with both the preexisting
Cygwin Win32 locking VFS as well as the POSIX locking VFS in a single
executable. That would let me switch between them at run time using the
environment variable I've already defined.
It's easy enough to add that to Cygwin, so I'll do that within the hour.
That requires another sqlite test release, obviouly.
Okay, I've just released a set of -2 packages.
It required a spelunking expedition, complete with yak wagons and a team
of five sherpas, one of which had to be left behind with a broken leg,
but I figured out how to compile in the BSD locking VFS without
disabling the POSIX one, then how to make SQLite switch between them at
runtime. (This is what gives me hope for Plan C, above.)
The CYGWIN_SQLITE_LOCKING variable now has three possible states:
CYGWIN_SQLITE_LOCKING=posix -- same as before
CYGWIN_SQLITE_LOCKING=posixmand -- equivalent to leaving it undefined in
the 3.7.17-1 build
CYGWIN_SQLITE_LOCKING=AnythingElse -- BSD flock() based mandatory locking.
(Yes, this means there's no way to make it use BSD advisory locks. I
couldn't come up with a good reason to add that fourth code path, but if
it's needed, I'll add it.)
Same download path as before: http://etr-usa.com/cygwin/sqlite3/
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple