X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,SPF_HELO_PASS,TW_SV,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Achim Gratz <Stromeko AT nexgo DOT de>
Subject:	Re: cygwin 1.7.15: svn disk I/O error
Date:	Wed, 20 Jun 2012 07:25:13 +0200
Lines:	33
Message-ID:	<87395qh7wm.fsf@Rainer.invalid>
References:	<jrdf56$61r$1 AT dough DOT gmane DOT org> <CE9C056E12502146A72FD81290379E9A4361BBA1 AT ENFIRHMBX1 DOT datcon DOT co DOT uk> <jrqjko$dc3$1 AT dough DOT gmane DOT org> <87pq8vxaok DOT fsf AT Rainer DOT invalid> <4FE117BA DOT 1020909 AT etr-usa DOT com>
Mime-Version:	1.0
User-Agent:	Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)
X-IsSubscribed:	yes
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

Warren Young writes:
>> Note that SQLite isn't really designed for concurrent access
>> to the database file from a different process.
>
> There is a paucity of truth in that statement.

So let me re-formulate that sentence: concurrent access ultimately
relies on the file locking provided by the OS.  The concurrency support
in SQLite is simply to not keep state outside a critical section and
lock the database file exclusively when entering one.

> But, there's only so much SQLite can do to cooperate with the OS's
> locking strategy.  On POSIX systems where SQLite was born, locking is
> mostly advisory and cooperative, whereas Windows gives you mandatory
> locks by default in a lot of cases.  Mandatory locks allow one process
> (e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to
> change a file, indefinitely.

Cygwin should (and apparently does) abstract away that difference.  But
it seems that the locking strategy might be slightly different between
Win32 and POSIX, triggering a foray into that "disk I/O error" branch.
There may still be a bug some place else, i.e. it may get a timeout
rather than a "file locked" state.  I'll have a look when I find some
time.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


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