Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.programming.threads,comp.unix.programmer Subject: Re: Safe accesses of global arrays in signal handlers? Date: Mon, 01 Oct 2012 18:04:04 +0100 Lines: 34 Message-ID: <87txuep1iz.fsf@sapphire.mobileactivedefense.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net 8sga3kr6kufJN5oMs4PF9gtcufPhARQWl7XMLwCad4x2xxFjyDM03wEO4GcE0a3xw= Cancel-Lock: sha1:1bDSqrA/wMCpiT+z5GBuuhpv9Ho= sha1:La4Tk9mWLCJBkf1FuWgUcT6O7Y8= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Xref: csiph.com comp.programming.threads:1147 comp.unix.programmer:3409 William Ahern writes: > Nobody wrote: >> On Sat, 29 Sep 2012 13:44:50 +0200, Markus Elfring wrote: > >> >> Yes. write() is async-signal-safe, so one thread can do a blocking >> >> read() and the signal handler can use write() to wake it. >> > >> > Thanks for your feedback. >> > >> > Do you see any difficulties or software design challenges for proper >> > handling of the situation that more data is written into the pipe than >> > the receiving thread can read and process in a timely manner? > >> The signal handler only needs to write one byte at a time; the receiving >> thread can read a pipe-full at a time. If the receiving thread does >> nothing but notify worker threads or enqueue messages, there shouldn't be >> a problem. > >> But you have a similar issue with the signals themselves. If non-realtime >> signals are generated faster than they are handled, pending signals aren't >> guaranteed to be queued, i.e. the handler may only be invoked once for >> multiple signals. > > The problematic issue is when SIGFOO fills the pipe, causing SIGBAR to get > dropped on the floor. That seems exceedingly unlikely, but I suppose you > could use one pipe per signal. Technically, when the program is receiving signals so fast that it doesn't get around to processing them anymore, that's a livelock and in this case, something has to be dropped on the floor in order to restore the ability to make forward progress. Consequently, just setting the pipe descriptor to non-blocking and ignoring EAGAIN in the signal handler might be a sensible approach, especially considering that this is unlikely to happen for typical uses of signals.