signals == software interrupts ?
in [Unix Programming]
|
From: Barry Margolin on 8 Feb 2010 20:42 In article <878wb33903.fsf(a)fever.mssgmbh.com>, Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > The reason the loop works with the sleep(0) is presumably because > whatever code gets executed because of the call might have changed the > value of RUN and hence, the compiler generates code to check this. Seems like a pretty poor optimizer. Unless RUN is an external variable, or &RUN is assigned to an external variable (or some chain of address assignments eventually leads to an external), how could an external function change its value? This is Data Flow 101, isn't it? -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: Ben Bacarisse on 8 Feb 2010 20:59 Barry Margolin <barmar(a)alum.mit.edu> writes: > In article <878wb33903.fsf(a)fever.mssgmbh.com>, > Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > >> The reason the loop works with the sleep(0) is presumably because >> whatever code gets executed because of the call might have changed the >> value of RUN and hence, the compiler generates code to check this. > > Seems like a pretty poor optimizer. > > Unless RUN is an external variable, or &RUN is assigned to an external > variable (or some chain of address assignments eventually leads to an > external), how could an external function change its value? This is > Data Flow 101, isn't it? RUN is/was and external variable. -- Ben.
From: Rainer Weikusat on 9 Feb 2010 14:59 Barry Margolin <barmar(a)alum.mit.edu> writes: > In article <878wb33903.fsf(a)fever.mssgmbh.com>, > Rainer Weikusat <rweikusat(a)mssgmbh.com> wrote: > >> The reason the loop works with the sleep(0) is presumably because >> whatever code gets executed because of the call might have changed the >> value of RUN and hence, the compiler generates code to check this. > > Seems like a pretty poor optimizer. An optimizers whose 'invariant code motion pass' creates the fastest possible infinite loops by moving exactly everything out of a loop body, despite it is very likely that this wasn't intended and it really doesn't matter how fast an infinite loop can do a single iteration is indeed poor :->.
From: David Schwartz on 9 Feb 2010 16:50 On Feb 8, 7:48 am, Jorge <jo...(a)jorgechamorro.com> wrote: > Hello, > > I have a forked process that enters a loop like this: > > while (RUN) { >  //do nothing but burn the CPU > > } > > it also has a handler set for SIGALRM that just flips RUN to 0. > > Later on the parent sends it a kill(child, SIGALRM), and, the problem > is that the sent SIGALRM signal is never handled -I don't know why- > unless I put a sleep(0); inside the above loop. > > Why is this so ? Because your signal handler is broken. "If the signal occurs other than as the result of calling the abort or raise function, the behavior is undeï¬ned if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t[.]" - C99 7.14.1.1 The solution is simple -- declare 'RUN' as a volatile sig_atomic_t variable. DS
From: Rainer Weikusat on 10 Feb 2010 04:51
David Schwartz <davids(a)webmaster.com> writes: > On Feb 8, 7:48 am, Jorge <jo...(a)jorgechamorro.com> wrote: [signal handler setting assigning to an int object] > Because your signal handler is broken. > > "If the signal occurs other than as the result of calling the abort or > raise function, the > behavior is undefined if the signal handler refers to any object with > static storage duration > other than by assigning a value to an object declared as volatile > sig_atomic_t[.]" - C99 7.14.1.1 This except doesn't support the notion that 'the signal handler is broken'. Its behaviour may[*] be undefined, according to the C-standard, but this just means the code is not strictly conforming C but only conforming C (by virtue of being acceptable to a conforming application). Since the code was also using library functions not defined by the C-standard, it is 'just' conforming C either way. The meaning of 'not defined by the C-standard' is still just 'not defined by the C-standard'. [*] sig_atomic_t is a type which is supposed to be defined in the signal.h header. As such, it must be an alias for another type and in this particular case (Linux/ glibc), this other type is 'int'. Consequently, the behaviour is not undefined for this implementation and not for any other which also typedefs sig_atomic_t as int. |