atom feed9 messages in net.sourceforge.lists.courier-coneRe: [cone] Automatic Refresh for loca...
FromSent OnAttachments
Linux-FanDec 30, 2016 2:53 pm.txt
Sam VarshavchikDec 31, 2016 7:23 am 
Linux-FanDec 31, 2016 7:57 am 
Sam VarshavchikDec 31, 2016 9:27 am 
Linux-FanJan 1, 2017 2:15 pm 
Linux-FanFeb 1, 2017 1:42 pm.diff
Sam VarshavchikFeb 1, 2017 6:44 pm 
Linux-FanFeb 2, 2017 8:25 am.diff
Sam VarshavchikFeb 3, 2017 3:58 am 
Subject:Re: [cone] Automatic Refresh for local Maildir's mail counts
From:Sam Varshavchik (mrs@courier-mta.com)
Date:Feb 3, 2017 3:58:52 am
List:net.sourceforge.lists.courier-cone

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.

------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot