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

[Sam V. <mr...@co...>]

Linux-Fan writes:

> OK. I have changed the code to no longer rely on an atomic primitive. I
> have implemented this by maintaining two counters where the first one
> counts the number of signals received and the second one counts the
> number of signals processed. This way, there is no potential for losing
> a signal as there are no concurrent writes to the variables. (Well,
> theoretically signals may still get lost: If exactly 2^32 signals are
> received before Cone runs the function to detect pending updates, there
> will not be an update, because advancing the counter 2^32 times puts it
> back to it's initial position)

There is a reason why sig_atomic_t exists. The problem with sig_atomic_t is  
that it's unavailable on older platforms. There, platform-specific types  
were typically used for this purpose.

> I have not tried to do it with pipes because I find them more complex:
> Pipes need to be opened explicitely and I have not found a definite
> answer about the question whether POSIX specifies writing to a pipe
> from inside a signal handler to behave well-defined.

The write() system call is explicitly listed as being safe to call from a  
signal handler, see signal(7).

> Also, I am not sure (for the pipe-idea) what happens if for any reason,
> a lot of signals are received: My current solution will just keep

I believe I already pointed you to using non-blocking mode, for both writing  
and reading from the pipe. Once something is read from the pipe, loop and  
keep reading from it until it is completely drained.

This is, of course, entirely up to you. I'm just pointing out the direction  
I would've gone, in the same situation.