This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sqlite3: bug with monotone


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]