Ken wrote:
As discussed, this prevents sequence file corruption, but doesn't solve
the race condition you can get with rcvstore. So it occurs to me that we
should really solve that properly. Solving THAT means that we have to
lock the sequence file across a read()-change-write() cycle. How we
implement that is up in the air; right now that happens as part of
folder_read(), and sticking a write lock in there seems wrong. But
we could make functions that want to update a sequence call seq_read()
again to a) write lock the sequence file(), and b) re-read the sequence
file to update the folder structure with any changes. That would mean
keeping around a file descriptor longer (but not too much longer,
hopefully).
That's what I tried to address with a lock-and-read-again (below)
approach. Maybe it's the same as what your suggesting. But it
doesnn't require keeping the fd open. I don't think we want to
do that, esp. if locked.
We could change the current configure --with-locking to not
apply to the spool file lock. For that, and the nmh state
file locks unless overridden, use what configure now picks
for the default lock method. In other words, --with-locking
would only apply to the nmh state files. I think that
agrees with what Lyndon suggested, putting aside the default
lock method choice.
See, I was thinking the exact opposite; I think people think now that
--with-locking applies to spool files. But irregardless, I am thinking
that we should be switching to run-time configuration as much as possible.
Maybe --with-locking could set the default spool locking for a platform.
--with-spool-locking? Alternatively, --with-state-locking?
I agree that run-time config would be nice.
Would the added steps in [] below help?
open file, lock file, read file, unlock file, close file
[save entire file contents]
update sequences
open file, lock file
[read file]
[compare current file contents to saved file contents:
if the same, then write file
if not the same, then complain and leave file as is]
unlock file, close file
The user could see that there was a collision and wouldn't have
mangled files.
See, I don't think this is necessary. A brief look at the relevant
programs suggests to me that with a few API tweaks we can actually
maintain consistent locking across sequence files and (in most
cases) the locking window will be rather small.
Could you list out the operation sequences?
Context files are a bit harder, but I'm not sure that's as critical;
the information there isn't (generally) a large set being modified
by multiple programs at once. I think we can live with just
open/lock/write/close sequence there.
Context files hold private sequences, so I think they should
be managed the same as sequences files.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers