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(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers