[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Locking (specifically, sequences)

From: Paul Vixie
Subject: Re: [Nmh-workers] Locking (specifically, sequences)
Date: Sun, 10 Mar 2013 23:16:19 -0700
User-agent: Postbox 3.0.7 (Windows/20130120)


chad wrote:

Spitballing for a moment: I wonder if we can detect the case where
the sequence file changes out from under an operation.  If so, it
might be possible to save the original data, compute a delta of
some sort, and use that to repair the sequence, or punt to the user?


I used to see this problem (rarely) with a periodic fetchmail+slocal
setup, and 'folder -pack' was almost always enough to make the world
right. On the other end, things like rsync, hg, and git have advanced
the state of the art in version-skew management a fair bit since
those days.

Just an idea; I hope it helps.

sometimes we get logjammed on hard problems and have to figure out what 
"the MH way" is in this case. i know that the MH way is not "corrupt the
 .sequence file so that all subsequent MH commands fail with an error 
message" and that's why i sent the patch in 2003 that made rcvstore use 
the locking version of fopen rather than the raw libc fopen. however i 
don't think the MH way is "compute a delta of some sort". i propose that
 the locking fopen function in the MH library be adapted to be willing 
to try the advisory lock three times at one second intervals, on the 
assumption that no writer will hold the lock that long and if there's a 
convoy then we've got bigger problems. (ideally we'd do a wait-lock in a
 thread and kill that thread if it waits too long, but threads would not
 be "the MH way".)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]