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
