Re: [mmh] Previous-Sequence
[2020-03-24 23:38] Philipp Takacs Hi, > [2020-03-24 08:56] markus schnalke > > [2020-03-23 21:46] Philipp Takacs > > > A updated version of my patches is attached, including the updated > > > man pages. > > > > Please add a HISTORY section to the mh-sequence(7) manpage with > > some explanation about the removal of the Previous-Sequence, so > > that people, who search for it, are informed that it was removed > > and why. > > > > Then it's ready to commit, I'd say. > > OK I have added following: I tried editing the wording a bit to make it read better. > --- a/man/mh-sequence.man7 > +++ b/man/mh-sequence.man7 > @@ -263,5 +263,24 @@ in your profile with an empty value. > .SH "SEE ALSO" > flist(1), mark(1), pick(1), mh-profile(5) > > +.SH "HISTORY" > +.SS Previous\-Sequence > +Earlier versions of > +.B mmh > +supported the `Previous\-Sequence'. This sequence stored the selected messages for the previous mmh command. It was disabled by default because it introduced a lot of extra writes to the .mh_sequences file. Additionally, it introduced possible race conditions when running multiple mmh commands in parallel. The feature was removed for these reasons. [..] -- Simon Thelen
Re: [mmh] show sequences racecondition and Previous-Sequence
[2019-12-15 17:55] Philipp Takacs > part 1 text/plain1256 > Hi Hi, > I have looked at the problem with open pager for show and change the > sequences during the pager is open. This happen often, if you show a > message and recieve a new message. This issue hits me pretty often because I'll have open several messages at once with a single show instance, and then while reading/responding new mails get delivered and .mh_sequences gets updated and then when I'm done with the mails I'll close the pager and show overwrites the .mh_sequences thereby silently losing the unseen flag on any newly added messages. > During that I found the Previous-Sequence again. I don't see a reason > why we need this feature. The usecases, I see, for the feature are better > handled with mark or the backlog of your shell. But I don't use this > feature. [..] I don't personally use the Previous-Sequence option, so I can't comment here. > So back to show I have two commits attached. One to remove the > Previous-Sequence and one to handle the unseen sequence better. If we > decide to keep the Previous-Sequence, I have to look at the race again. > > The unseen sequence has it's own flag beside the sequences in the > msgs struct. The seq_setunseen() function updates the unseen sequence > in this struct. So I have just moved the seq_setunseen() call to the > end and added a seq_read() call before. This way it's still a bit racy > but not this hard. To fix the rest of the race we could add locking. The attached solution works well enough for me, though adding locking would of course be nice. -- Simon Thelen
