So it wouldn't be a change to nmh without wide-reaching complications. As I said earlier this week, I commited the locking code to nmh. David Levine reported to me that he now gets a 5-second hang when he deletes a message.
We tracked this down to the fact that his rmmproc calls "scan", and given the current architecture of the code, during the invovation of rmmproc the sequence file is locked and thus "scan" hangs trying to open the sequence file until the lock times out. It seems reasonable to want to be able to invoke nmh commands from rmmproc, although that was never clearly defined as reasonable (or even if it was expected to work). I think it's reasonable to do, but clearly this was something the original MH coders never anticipated. So I'm open as to suggestions on what to do here. Possibilites that come to mind are: - Update the sequence file _before_ calling rmmproc(). This would happen in the folder_delmsgs() routine. This technically involves an API change, but the nmh API has no real definition and only two callers, so I'm not really worried about that part. - Do nothing. Not as weird as it sounds; if messages aren't on the sequence, they'll get removed next time the sequence file is written. - Reread the sequence file after deleting the messages but before writing it out; possibly challenging because the messages will be gone, but they should be removed anyway. - Set an environment variable to indicate that subprocesses shouldn't open or modify the sequence file. I have no idea what the "right" answer is. Suggestions? --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers