This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: sqlite3: bug with monotone
- From: Warren Young <warren at etr-usa dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 31 May 2013 14:19:40 -0600
- Subject: Re: sqlite3: bug with monotone
- References: <51A6B6EB dot 6050309 at users dot sourceforge dot net> <loom dot 20130530T122354-144 at post dot gmane dot org> <51A7862F dot 1070507 at etr-usa dot com> <51A7D47E dot 3050502 at users dot sourceforge dot net> <51A7F547 dot 6020509 at etr-usa dot com> <20130531092228 dot GB30659 at calimero dot vinschen dot de> <51A900EF dot 2020606 at etr-usa dot com>
On 5/31/2013 13:58, Warren Young wrote:
The SQLite code prefers POSIX advisory locks, but it can fall back to
BSD locks if it has to.
Just to clarify, when I say "POSIX locks" I always mean new style
fcntl() locks. There are no calls to lockf() in sqlite3.c.
I'm not sure why it doesn't just
blindly try the lock.
On reflection, I'm sure it has something to do with maintaining high
concurrency. If it knows its near-future DB file write is going to get
blocked, it can choose to do something else while the existing DB lock
holders finish.
By contrast, SQLite's flock() based locking is documented as being much
more brute-force, resulting in much lower concurrency.
--
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