This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [TEST] sqlite3-3.7.17-1 (Cygwin 1.7.19 locking feature)
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin at cygwin dot com
- Date: Thu, 06 Jun 2013 20:17:12 +0200
- 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> <51AF9A32 dot 2030706 at etr-usa dot com> <20130606172218 dot GD13320 at calimero dot vinschen dot de>
Corinna Vinschen writes:
> In theory this scenario could be worked around in Cygwin by bookkeeping
> the present locks, plus a piece of code which unlocks all existing locks
> in the given range when a lock or unlock request is coming in. However,
> the really dismal fact is, that an unlock before a lock would never be
> atomic. If the F_SETLK request unlocks an existing lock and then
> another process gets a lock in the requested range, the first process
> ends up with a failed fcntl call and no lock at all.
Thanks for the explanation, I'm beginning to see what the backoff / retry
code in SQLite on WIndows is supposed to be doing (hopefully).
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
--
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