Re: (Fwd) Re: [PATCH] db/gdbm rewrite

[Sebastian Gniazdowski <psprint2@fastmail.com>]

On Sat, Feb 18, 2017, at 04:43 PM, Bart Schaefer wrote: 
> On Feb 14,  4:20am, Sebastian Gniazdowski wrote:
> }
> } -- hashtable is filled normally, initially with ~PM_UPTODATE
> } -- Param "dereference" detects ~PM_UPTODATE, uses database, sets u.str,
> } sets PM_UPTODATE
> 
> This is not going to provide equivlent behavior, is it? If the database
> is being read by zsh and updated by some other process, how does zsh know
> that it needs to re-fetch what has now become a cached value?

As the other thread pointed out, GDBM_SYNC flag means no change to
database can be done, even when opening in read-only mode. This is
certain, and allows PM_UPTODATE to be used. The possible concurrent
change in Zsh forked process is a hole. It can be turned into an
feature, though. A new builtin "zgdbmfetch paramname key" could be
provided to re-fetch element when someone is going to try to do
concurrent access with inherited FD and GDBM_SYNC lock, say with use of
zsystem flock on other FD.

-- 
Sebastian Gniazdowski
psprint2@fastmail.com