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

[Ken Hornstein]

>Is this a problem for nmh?  I don't think so.  Here's what
>we do in context_save():
>
>    if (!(out = lkfopen (ctxpath, "w"))) adios (/* not shown */);
>    /* write the context to the file */
>    lkfclose (out, ctxpath);

Well, this gets into something ELSE I wanted to bring up.

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).

>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.

>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.

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.

--Ken