[Resolvconf-devel] Bug#213591: Could be implemented using watershed

[Thomas Hood]

I wrote eight years ago:
> The following race remains theoretically possible:
>
>   resolvconf #1 and resolvconf #2 both look at the old version
>   of record R and both update record R.  Both think that R has
>   changed, so both run the update scripts.  But actually only
>   the one whose changes stomped on the other's needs to run the
>   update scripts.


The watershed program, currently in the chiark-utils-bin package, has
two attractive features which could be useful in resolvconf.  First,
it serializes multiple invocations of a program; second, it omits
redundant invocations.

Illustration.  Suppose invocations A, B and C of idempotent program P
come in at about the same time and A happens to be first.  Watershed A
starts process PA.  Next B comes in.  Watershed B queues process PB.
(Although P is idempotent, PB is needed because P's input data might
have changed.)  Then C comes in while PB is still queued.  Watershed C
waits for PB, but does not queue another process since PB suffices.

Resolvconf could use watershed to serialize and to de-redundantify the
update phase.

To be correct, though, we would still need to serialize resolvconf's
accesses to individual records, and watershed wouldn't help with that.

All this stills seems rather academic after eight years of resolvconf
with not one report of a failure attributable to these races.
-- 
Thomas