Peter:
> On 27/07/16 09:51, Viktor Dukhovni wrote:
> >
> >> On Jul 26, 2016, at 5:12 PM, Peter <pe...@pajamian.dhs.org> wrote:
> >>
> >> Would doing another cache read right before the update be an easy fix
> >> for this? I do realize this would add additional latency to postscreen,
> >> hopefully not too much.
> >
> > This still leaves a race condition in place, though it would be for a
> > shorter
> > time.
>
> The shorter time should be good enough, but I would think you could lock
> the db for the operation to prevent the race.
That would not help. postscreen is normally the only reader/writer.
Only LMDB maps support write/read and write/write sharing, and that
only with the locking scheme described lmdb_table(5).
A better solution is to eliminate the redundant cache access and
update when sessions from the same client overlap in time.
Wietse
