[Nmh-workers] Locking complications

[Ken Hornstein]

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