Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [PATCH] db/gdbm rewrite
- X-seq: zsh-workers 40595
- From: Sebastian Gniazdowski <psprint2@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: [PATCH] db/gdbm rewrite
- Date: Mon, 20 Feb 2017 00:32:25 -0800
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=PJiSj9imYORFQZmPJ8a1O+eVCI A=; b=SAg8XZwMwYQuXft16ZNXavIF9Ut2ifLBI0Uudd17cxDPbHP5Qda6jcfVnZ d6SW2R4wIbDpYdT1wTuiCQq5J7yCy6HDu8ixGti67VtB7485xSOpQHQ5y2O8qIFs eDaCcBk7yYlJS1y6U/80kQCSJrsdVh4oWqVwBA5/G+q6HtdAw=
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=PJ iSj9imYORFQZmPJ8a1O+eVCIA=; b=qWhL4iqhF4tT9oR/yIwimYXHXwdYcpSV7P 5U09lXPL6SF4yl4IlIni1k4M83adGrv7AtYYlbAQ7Ul8p0+EYbLf0bqrM2lJO/YL rD8AixC2fTU54fa70g4iCxcsN9hMzmR0pweFzdE9zQSyvrQrfmdkjS0zJN+1smCx bwrfUVOWE=
- In-reply-to: <170219101917.ZM22858@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <170218164313.ZM10688@torch.brasslantern.com> <1487494013.288657.885684608.5BB76024@webmail.messagingengine.com> <170219101917.ZM22858@torch.brasslantern.com>
On Sun, Feb 19, 2017, at 10:19 AM, Bart Schaefer wrote:
> GDBM_SYNC is meaningless for read-only mode; in any write mode it means
> that changes made to by the program are immediately flushed out to the
Ah, I had a matrix on my eyes and read GDBM_SYNC as GDBM_LOCK.
> Man page also says:
>
> It is important that every file opened is also closed. This is needed
> to update the reader/writer count on the file.
>
> Why would there be a reader/writer count if there is no concurrent change
> allowed?
It must be for multiple threads. Sorry for not reading the docs doing
update, but by testing gdbmtool behavior I have got correct image:
- database access is guarded by locks
- writing to single file by 2 threads without locking corrupts database
- gdbm isn't a server and doesn't order transactions with a level of
concurrency
We could update db_gdbm to use GDBM_NOLOCK and seamlessly ~PM_UPTODATE,
providing a zgdbmlock builtin. I did a good thing with PM_UPTODATE, all
doors are open.
--
Sebastian Gniazdowski
Messages sorted by:
Reverse Date,
Date,
Thread,
Author