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=H46BE5e/OzFFShVC6iaTU7vcu7CH1CM7uOdfi8hVw+T
	7ZoWYHFJGsryy+ndNtrXx1U8BJ1O0bmeYYULcbXNkyZjF41kuRHNj+WbEiSD+lRo
	Y/NJBt+ztkSutWqzOmQxrrDqWvGLvkHGdVWMI+UY71S/s7T24oYdLguEnVpN1ces
	=
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=7HupL4cVfiOF5l590/OUxov/MXU=; b=O7HVucin1xFplnvIF
	jjeajothuV3QpAQyRxy+x6v0cVgY5J3ms9k99RsHsNGEjqQw5jANEe5lOizS1vIw
	G1UohUUfhqMt3crLeXQm046D63eJhzZPZL+AggD6k2+pUVKorlYa5BlBlMgds5W2
	7EdZIjsiaL6Y6FqChkSKicpkMY=
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.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Message-ID: <51AF9A32.2030706@etr-usa.com>
Date: Wed, 05 Jun 2013 14:06:10 -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: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)
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> <20130604093749 DOT GA32667 AT calimero DOT vinschen DOT de>
In-Reply-To: <20130604093749.GA32667@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 6/4/2013 03:37, Corinna Vinschen wrote:
>
> 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.

SQLite locking is a hairball.  It is spread over a range of about 2.5 
kLOC within the 140 kLOC sqlite3.c file, and those routines are behind 
about three layers of indirection from the mainline SQLite code.

Mind, I'm not talking about the *callers* of this code here, just the 
locking routines themselves.  Add in all the callers and *their* 
expectations and...well...<shudder>

I think we have to define the problem as "SQLite locking requires what 
SQLite requires today."

Luckily, while creating the -2 packages, I stumbled across a STC in SQL 
that replicates the reported problem:

$ ./sqlite3 foo.db 'create table fred(id integer, barney text)'
$ CYGWIN_SQLITE_LOCKING=posixmand ./sqlite3 foo.db \
   'insert into fred(barney) values("wilma")'

If you change the locking mode to either "bsd" or "posix", it doesn't 
fail.  This gives hope that your new flock() implementation may work for us.

Here's hoping you can get the info you want from running the second 
command under strace.

I can tell you that it doesn't fail if you don't do a DB write.  For 
example, this succeeds regardless of locking strategy:

$ ./sqlite3 foo.db .q

You can see it open the DB file and turn on mandatory locking, but since 
it doesn't write to the DB file, it doesn't actually call flock().  The 
same goes for the other two locking strategies.

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