kh>Well, think about what's going on. You're changing sequences in the
kh>middle of an operation which is changing sequences. At a minimum you're
kh>going to be on the fringe of supported behavior.
But other than the explicit calls to mark and Previous-Sequence,
sequences oughn't be being touched...?
Well, it works out that since pretty much every command modifies the previous
sequence, that means that essentially every command rewrites the whole sequence
file if you have a Previous-Sequence set.
And I thought commands were
meant to open, close, reread sequences as needed rather than keep
a long lock? This is add-hook from rcvstore, via slocal.
Well, I'm not sure exactly that they were "meant to" do that. In terms of
implementation details, I did that for what I considered "long running"
commands. Currently the two "long running" commands are inc and pick.
That's not to say that I didn't take care to make sure locks aren't held for
an excessive amount of time. For example, it's not like show holds a lock
for it's entire execution. It decides what messages to read, modifies the
context and sequences as necessary, releases the lock, and then displays
the messages.
Might rcvstore be keeping a lock on the sequence file for too long?
It just occurred to me that what I previously thought was mime-add-hook
running slow is probably the script waiting for filelocks;
although `mhparam lockmethod` reports "none" (David says the last bit
is a bug he's looking into)
Looking at the sequence of things that rcvstore does, it's:
- Copy incoming messages to temporary file.
- Read destination folder and obtain lock
- Add message to folder using folder_addmsg().
- Do any additional sequence manipulation specified on the rcvstore
command line.
- Save sequences and release lock.
That looks to me like it's holding the lock for an appropriate amount
of time.
Now, folder_addmsg() calls either the add-hook or ref-hook, so yeah, it
will be called with locks set. I think pretty much every caller of
folder_addmsg() will be called when locks are set (inc does not call
folder_addmsg()).
Hooks are a relatively new addition to nmh, and it was never really defined
very well what you could expect to work inside of them. I am unsure how
we can guarantee that you can safely modify nmh metadata INSIDE of a hook
when running a program that also modifies nmh metadata; that way seems
to lie madness.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers