sqlite3: bug with monotone

[Warren Young]

On 5/31/2013 03:22, Corinna Vinschen wrote:
> On May 30 18:56, Warren Young wrote:
>> 1. We continue waiting for someone to to implement a per-process or
>> per-subtree mandatory locking feature in Cygwin, so that "Unix mode"
>> SQLite on Cygwin can be configured to cooperate with native SQLite.
>
> What kind of locking does sqlite use on Cygwin:
>
> [ ] POSIX fcntl locks
> [ ] BSD flock locks
> [ ] Old POSIX lockf locks?

The SQLite code prefers POSIX advisory locks, but it can fall back to 
BSD locks if it has to.

The docs and code comments talk about the choice between the two being 
dependent on the "file system", so that SQLite can use flock() where 
POSIX locks don't exist.  My understanding of the code is shaky, but it 
looks like it tries POSIX locks when opening the DB file and falls back 
to BSD locks if that fails.

(Part of the reason I'm shaky on this is that it's actually a lot more 
complicated than that.  There are seven (?) locking strategies supported 
by the current code, only some of which are compiled in at any one time, 
depending on the platform.  On top of that, all of this runs through 
SQLite's VFS indirection layer, so tracing the calls is a bit like 
Choose Your Own Adventure.)

If I had to guess, I'd say SQLite in Unix mode will use POSIX locks on 
Cygwin, provided they work as it expects.  If cygwin1.dll doesn't do 
what SQLite expects when it tries the lock, it may fall back to flock().

> Here's a proposal:
>
> - Only add optional mandatory locking to fcntl and flock locks, not for
>    lockf locks.

Okay so far.

> - Add a flag F_MDLCK which can be or'ed to struct flock's l_type.
>
> - Add a flag LOCK_MD which can be or'ed to the 2nd parameter to flock(2).

I'm uneasy about this departure from SysV mandatory locking.  (Nicely 
described in Linux's Documentation/mandatory.txt.)

I guess you're doing this because the setgid + g-x hack the SysV 
implementors chose can't work on NTFS?

> - Using these flags, I'll resurrect the old pre-Cygwin 1.7 locking code
>    which does NOT support F_GETLK.

SQLite does use F_GETLK.

Four of the five uses in the code appear irrelevant to Cygwin.

The fifth, though, is that SQLite uses F_GETLK when it is in the path 
where it knows it will need to write to the DB "soon" but not 
immediately, so it attempts to get the current lock to see if it's 
currently unlocked before proceeding.  I'm not sure why it doesn't just 
blindly try the lock.

See unixCheckReservedLock() near line 24210 in the amalgam version of 
sqlite3.c.

> Does that sound ok?

Your previous proposal was to implement Linux's -omand mount option. 
There's a lot to recommend it.

For one thing, someone wanting Cygwin SQLite to behave as it currently 
does despite being built in Unix mode should be able to set this option 
on the Cygwin root and /cygdrive, no?

Those wanting a more nuanced approach can remount subtrees of their 
native filesystem with it, where they know they need it.

I suppose you could do like Linux here, and ignore the flags you've 
proposed adding when the subtree isn't marked as wanting mandatory 
locks.  If you did it that way, then these flags would operate more like 
the SysV file modes hack, being necessary to enable mandatory locks on 
that file but not sufficient.

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