Path: csiph.com!usenet.pasdenom.info!gegeweb.org!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <python.list@tim.thechases.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.020
X-Spam-Evidence: '*H*': 0.96; '*S*': 0.00; 'subject:file': 0.07; 'noted,': 0.09; 'permissions': 0.09; 'python': 0.11; 'thread': 0.14; '(low': 0.16; '-tkc': 0.16; 'disc': 0.16; 'flush': 0.16; 'from:addr:python.list': 0.16; 'from:addr:tim.thechases.com': 0.16; 'from:name:tim chase': 0.16; 'hardware.': 0.16; 'simpson': 0.16; 'sqlite': 0.16; 'subject: \n ': 0.16; 'url:faq': 0.16; 'url:sqlite': 0.16; 'prevent': 0.16; 'wrote:': 0.18; 'do.': 0.18; 'commit': 0.19; 'config': 0.24; 'lets': 0.24; "haven't": 0.24; "i've": 0.25; 'compiled': 0.26; 'mention': 0.26; 'possibly': 0.26; 'subject:/': 0.26; 'gets': 0.27; 'header:In-Reply-To:1': 0.27; '[1]': 0.29; 'tim': 0.29; '[2]': 0.30; 'code': 0.31; 'away.': 0.31; 'chase': 0.31; 'forces': 0.31; 'file': 0.32; 'open': 0.33; 'limitation': 0.33; 'actual': 0.34; "i'd": 0.34; 'could': 0.34; 'except': 0.35; 'something': 0.35; 'charset:us-ascii': 0.36; 'subject:?': 0.36; 'similar': 0.36; 'url:org': 0.36; 'level': 0.37; 'to:addr:python-list': 0.38; 'files': 0.38; 'anything': 0.39; 'does': 0.39; 'extremely': 0.39; 'to:addr:python.org': 0.39; 'according': 0.40; 'lost': 0.61; 'back': 0.62; 'making': 0.63; 'places': 0.64; 'subject:more': 0.64; 'different': 0.65; 'taking': 0.65; 'situation': 0.65; 'within': 0.65; 'believe': 0.68; 'physical': 0.72; 'nfs': 0.84; 'received:50.22': 0.84; 'safe.': 0.84; 'subject:read': 0.84; 'shares': 0.93
Date: Sun, 15 Dec 2013 18:07:54 -0600
From: Tim Chase <python.list@tim.thechases.com>
To: python-list@python.org
Subject: Re: Is it more CPU-efficient to read/write config file or read/write sqlite database?
In-Reply-To: <20131215231228.GA6608@cskk.homeip.net>
References: <20131214101518.69b040dc@bigbox.christie.dr> <20131215231228.GA6608@cskk.homeip.net>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - boston.accountservergroup.com
X-AntiAbuse: Original Domain - python.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - tim.thechases.com
X-Get-Message-Sender-Via: boston.accountservergroup.com: authenticated_id: tim@thechases.com
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.4158.1387152409.18130.python-list@python.org>
Lines: 49
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1387152409 news.xs4all.nl 2880 [2001:888:2000:d::a6]:51839
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:61974

On 2013-12-16 10:12, Cameron Simpson wrote:
> On 14Dec2013 10:15, Tim Chase <python.list@tim.thechases.com> wrote:
> Annoyingly, sqlite:
> 
>   + only lets one process access the db at a time, taking you back
> to a similar situation as with config files

Is this a Python limitation?  According to the docs[1], it's not a
sqlite limitation (except, as noted, on non-locking filesystems like
NFS)

>   + only lets you access the db from the same thread in which it
>     was opened, outstandingly annoying; I've had to gratuitously
>     refactor code because of this

I do believe that limitation does hold though depending on the
build-options with which sqlite was compiled [2], though it might be
somewhat different from within Python where the GIL could
possibly prevent actual OS-level-thread issues.

>   + traditionally, sqlite is extreme fsync() happy; forces a disc
>     level flush on each commit - extremely slow on busy databases,
>     not to mention hard of drives

I'd say this is the right thing for a DB to do.  If it comes back
from a commit() call, it better be on that disk, barring a failure
of the physical hardware.  If it comes back from a commit() and data
gets lost because of a power-failure, something is wrong.

> > * well, except on NFS shares and other places where file-locking
> > is unreliable
> 
> Backing off to config files, making a lock directory is NFS safe.
> So is opening a lock file for write with zero permissions (low level
> open with mode=0).

Interesting.  I haven't used NFS in a long time for anything other
than quick experiments, so it's nice to file this away.  Do you have
a link to some official docs corroborating what you state?

-tkc

[1] http://sqlite.org/faq.html#q5
[2] http://sqlite.org/faq.html#q6