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: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 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=-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 AT cygwin DOT com>
To:	cygwin AT cygwin DOT 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 AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<51ACF886 DOT 10301 AT etr-usa DOT com> <51AD3BB4 DOT 2010601 AT acm DOT org> <20130604084128 DOT GB19572 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
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

- Raw text -