X-Recipient: archive-cygwin@delorie.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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=OQcAmFvcBxpku4b8frOj01uTXhK3oRpyzcCuUFLFXQ9AZd5ReXPBw
	pY+VLLLYJayH6s0fkjxiGPUbiznOuzVImBcMosEuHsC7W4zfcaigUAt5oMN4lI5B
	rN5LVwXZ7bACB6q86coG/1K8rbwW41MFU7uQ7LAAYA6Noxf0YYioSY=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=63/3BfuIQubQUysV8In4URirhdA=; b=dmpxohrXZgyYjALP9+WFNDnbMVKH
	aXUYXXgP5ev8PFZPQQ4zUqgaHJzI3g7MFytGHDZPT6IaTOfUwriNEirsq8EQ8Yhj
	CY46Npz1gmvn30HXxgDmzGuGVZ9glCb++oh7fmwAvug6HdZ2XorLae0gUEKRtPJJ
	Zv7e7vAKQ3eR2vM=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,TW_FC autolearn=ham version=3.3.1
Date: Tue, 4 Jun 2013 11:37:49 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)
Message-ID: <20130604093749.GA32667@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <51ACF886.10301@etr-usa.com> <51AD3BB4.2010601@acm.org> <20130604084128.GB19572@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20130604084128.GB19572@calimero.vinschen.de>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Jun  4 10:41, Corinna Vinschen wrote:
> On Jun  3 17:58, David Rothenberger wrote:
> > On 6/3/2013 1:11 PM, Warren Young wrote:
> > > This is a big-push attempt at a version of Cygwin SQLite that will make
> > > everyone happy (ha!) whether they want POSIX advisory locking behavior
> > > or Windows mandatory locking behavior.  My part of the effort is being
> > > stubborn on this point and doing the basic testing and packaging.  The
> > > real magic was added by Corinna to yesterday's 1.7.19 cygwin1.dll snapshot.
> > [...]
> > ... 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
> > unless CYGWIN_SQLITE_LOCKING=posix.
> 
> The question now is: Why?

IOW: It would be nice to have a simple testcase (plain C, only Cygwin
POSIX calls, self-contained, yada yada) to see what sqlite expects in
POSIX lock mode.

> 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.
> 
> If so, mandatory locking via fcntl locks is pretty much useless in this
> scenario.  The application using it has to know that the semantics are
> different and so create another code path which respects the annoying
> Windows lock behaviour (like the fact that a write lock blocks another
> write lock even if both are requested by the same process using the same
> HANDLE).
> 
> A potential workaround is to use BSD flock locks in sqlite.  Given that
> they lock the entire file, the behaviour is not so prone to the problems
> of Windows locks.
> It's easy enough to add that to Cygwin, so I'll do that within the hour.
> That requires another sqlite test release, obviouly.

As for "potential": If sqlite tries to convert an existing flock lock
into another type (read lock <-> write lock), this, too, will fail with
Windows locks underneath.  Windows locks require that the existing lock
is unlocked first.

Which gives me an idea.  What if each call to F_SETLK{W} first calls
NtUnlockFile on the given offset and length parameters?  This would
allow overwriting locks held by the same descriptor.  This should at
least help the flock case and often even in the fcntl case.  The fcntl
case which is not solvable is splitting and merging of existing locks.

[...time passes...]

On the other hand, this is non-atomic.  What could happen then is that a
flock call unlocks the existing lock, a task switch occurs, another
process locks the file successfully, and the flock call fails with an
unlocked file (LOCK_NB), or waits until further notice.  And then the
application might not find what it's expecting.

That's SO sick.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

