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

[David Levine]

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