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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
