Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!dedekind.zen.co.uk!zen.net.uk!hamilton.zen.co.uk!reader01.nrc01.news.zen.net.uk.POSTED!not-for-mail From: Nobody Subject: Re: Safe accesses of global arrays in signal handlers? Date: Fri, 28 Sep 2012 18:26:07 +0100 User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.programming.threads,comp.unix.programmer References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Lines: 20 Organization: Zen Internet NNTP-Posting-Host: 33b8f6a1.news.zen.co.uk X-Trace: DXC=b\dQWT2Nd8PS^RFZ\dPNcWa0UP_O8AJo\=dR0\ckLKGPWeZ<[7LZNRV1<`:M]jF@HRM2Z^cWRFGA[R4H^=7`GaO^ X-Complaints-To: abuse@zen.co.uk Xref: csiph.com comp.programming.threads:1111 comp.unix.programmer:3367 On Fri, 28 Sep 2012 13:48:40 +0200, Markus Elfring wrote: >> Doing anything substantial in a signal handler is problematic. > > Are the following approaches valid software design options for the > discussed use case? > > 1. "Self-pipe trick" that was described by Daniel J. Bernstein. > http://cr.yp.to/docs/selfpipe.html Yes. write() is async-signal-safe, so one thread can do a blocking read() and the signal handler can use write() to wake it. > 2. Are lock-free algorithms applicable like an implementation is described > in the article "Signal-Safe Locks"? Lock-free algorithms require memory semantics beyond those specified in the C and POSIX standards. E.g. they typically require the use of a memory barrier (fence).