This is the mail archive of the
mailing list for the Cygwin project.
Re: sqlite3: bug with monotone
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Sat, 1 Jun 2013 12:58:13 +0200
- 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> <51A905DC dot 6020109 at etr-usa dot com>
- Reply-to: cygwin at cygwin dot com
On May 31 14:19, Warren Young wrote:
> 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.
Makes sense, given that flock is not record but file locking.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple