X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=sGbrMTiXvNkvIhJf7a1078rzRsaUYCZ1d1l3zK9Uieu
	ksFOuRyD+JycHGZIGtd9KxIvlyKmjvmrvpvCqr6QATNmvaLX6cdBi1u5yHy7sBmr
	If4dLazIM/g9wb9XHW79x04cV04+RJPWxklm3OO6Ev1sQ+lYG1cAbQ2+UeoAkRdY
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=72dA3qX1c5WC/K3llFsT4LvHsUE=; b=rHUR4SVsV6KKyrXsX
	d7OH77dn2oLB8xdg0bpcWSQv1gz9Bj9VaYb5mfzjU3tmAumdb9fsj7S5flICJsq7
	KKn1bzhWOOCRZAeBb1wZpaN676ohdFIHbH13/Er2X0y9v8oa+mjDyWfIwLSUIM/o
	jvfUadLbeS8OZP9LjdFVXiIXDs=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Spam-SWARE-Status:	No, score=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,TW_FC autolearn=ham version=3.3.1
Message-ID:	<51A900EF.2020606@etr-usa.com>
Date:	Fri, 31 May 2013 13:58:39 -0600
From:	Warren Young <warren AT etr-usa DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: sqlite3: bug with monotone
References:	<51A6B6EB DOT 6050309 AT users DOT sourceforge DOT net> <loom DOT 20130530T122354-144 AT post DOT gmane DOT org> <51A7862F DOT 1070507 AT etr-usa DOT com> <51A7D47E DOT 3050502 AT users DOT sourceforge DOT net> <51A7F547 DOT 6020509 AT etr-usa DOT com> <20130531092228 DOT GB30659 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20130531092228.GB30659@calimero.vinschen.de>

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

- Raw text -