Re: [Nmh-workers] Locking complications

[David Levine]

Ken wrote:

> 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 this man page note indicates that it was considered
reasonable, though hazardous without some minimal care:

    rmmproc must NOT call refile or rmm without specifying -normmproc,
    or you will create an infinite loop.

And the -normmproc switch was added specifically to support that.

> 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.

I vote for that.

> - 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.

Yes but an intervening folder -pack would mess that up.

> - 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.

What's the advantage of this over door #1 (update before calling
rmmproc)?  If it just to minimize API/code changes, I don't
think that's enough.

> - Set an environment variable to indicate that subprocesses
> shouldn't open or modify the sequence file.

I'm not fond of environment variables.  While they can be
useful to modify the behavior of rmmproc, etc., I don't
think that's the right thing to do here.

David