nmh-workers
[Top] [All Lists]

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

2013-03-07 23:56:28
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

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>