Re: Automatic Refresh for local Maildir's mail counts

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--===============5501432719843000816==
Content-Type: multipart/signed;
	boundary="=_monster.email-scan.com-13474-1486123132-0001";
	micalg=pgp-sha1; protocol="application/pgp-signature"

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_monster.email-scan.com-13474-1486123132-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

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.



--=_monster.email-scan.com-13474-1486123132-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIcBAABAgAGBQJYlHB8AAoJEGs6Yr4nnb8l56sP/jwGhNSdPo/6kg4ny7+tuwHt
vjeZQOOpOckxSo+1mbPkE/Rlv4Ll0ZiaV3zZK3h2Yauo/e5i+RX9XrVm53Yvm7o/
7mSYuNgbgl/ZaJlBQ76V6ebuXLjkn/7QikxbTtyVbeSEyLX9P+rPW8uQAciUYz+p
cPnsaX2sYXJz1F6neALNsID59ApTOX2VbCzkbdITQ8oqM4BRNkhxjwTCWRhFjgSf
KTlhqus3HT7gsrjlQUyyod6dhjYM/hmlqoJ75frDqs0ii7aPm78qMT1QSFo1w7Ws
4Vlu56+l1jQN1SZj6Qz+8J9lCCzebUMpqmezakqx19Vjkuav7xf3l91sAZgZmY7+
MkwKpGkKEoDvncfAnIdp2gX9PLLWsHI4Diw72hz6AAIEKQNXV0URVxej76vTcy6T
TU2m6j334dm1WcdYzzYdVTFyAmbq2Vqrkeqc+P0AydOxUTB1MN41vkh/3CczuXlH
t4CreGUL4glj/0fGCs0LvIBTLfOnMfi7W2Is9VhevudQTHR3Ijyv+MoVg1sARFix
JwF4+v/QJDf7FU1JPnp/4DfFeZM5an/zJszG+VsNCI3XaH3lnhwaoHnrAAusmW1R
GHtSkudQI/hkGPeb2u47k9A/ayeIPtnEf+CwyGqhq+e20Wu8OZ+yXC8yqHTCgbCx
tJiZ+xnfNitG8y5J+Sie
=NXHO
-----END PGP SIGNATURE-----

--=_monster.email-scan.com-13474-1486123132-0001--


--===============5501432719843000816==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
--===============5501432719843000816==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Courier-cone mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-cone

--===============5501432719843000816==--