Re: [cone] Automatic Refresh for local Maildir's mail counts

[Linux-Fan <Ma_...@we...>]

[Sun, 1 Jan 2017 23:15:02 +0100] Linux-Fan <Ma_...@we...> wrote:
> [Sat, 31 Dec 2016 12:27:38 -0500] Sam Varshavchik
> <mr...@co...> wrote:
> > Linux-Fan writes:

[...]

> > > Is it possible/planned to add a means of updating the message
> > > counts from the folder hierarchy view automatically as well
> > > (similar to what I did upon receiving a SIGUSR1 for my
> > > proof-of-concept patch from the previous mail)?
> > 
> > I'm open to such a feature; however this approach won't work.
> > Signals
> 
> [...]
> 
> > The only safe way to do this: in addition to installing a signal
> > handler, an internal pipe needs to be created, and put into
> > nonblocking mode. The only thing the signal handler does is write a
> > byte to the pipe, ignoring the results, and immediately terminating.
> > 
> > Then, on the folder screen only, in addition to handling all the
> > regular events the read end of the pipe gets polled as well, and
> > when something is read, what your patch does would happen.
> 
> OK. I am going to check this out when I find time to dig into the
> source code again :)

[...]

I have taken on the challenge and tried to create a (more) correct
patch which enables cone-0.92 to update all folder's message counts
upon receiving a SIGUSR1.

It is not using a pipe, but a C++11 std::atomic instead. If that cannot
be used, because Cone needs to compile without C++11 (I used
`./configure CPPFLAGS=-std=c++11` to get it to work), I'd replace this
by a variable which is marked `volatile sig_atomic_t`.

What do you think? Does it make sense to put it that way or have I
misplaced the call to `processHierharcyRefresh()`? Is it better to use
`SA_RESTART` or not? I am not quite sure...
Also, in order to improve the folder refreshing mechanism, I have
implemented a `RefreshIterator` which uses `updateInfo` on all folder
entries. Have I used the API correctly?

> > Even with that, things may not work 100%. All the code needs to be
> > audited and verified that it'll correctly handle an interrupted
> > system call.
> >
> > Correct signal handling is hard.  
> 
> Yes it is :( Especially signal handling from within multithreaded
> applications is probably asking for trouble, so I understand that
> might not be the best solution here...

If signal handling is still too much of an issue with regard to the
overall application stability, might it make sense to replace my check
for `pendingUpdates.exchange(0) > 0` with a simple timer
(like if now - lastTimeOfCheck > NN seconds refresh)?

By the way: If you wonder about the `masysma` prefixes and annotations:
I will happily remove these if the patch has a chance of being
incorporated but for now I have added them to easily navigate to my
modifications within the code and make sure I do not confuse my
changes with what was already there...

Yours Sincerely and TIA
Linux-Fan

-- 
http://masysma.lima-city.de/