Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site calgary.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!alberta!calgary!radford From: radford@calgary.UUCP (Radford Neal) Newsgroups: net.unix-wizards,net.sources Subject: Re: When does ( alarm(1) == alarm(INFINITY) ) ? Message-ID: <1097@calgary.UUCP> Date: Fri, 8-Mar-85 17:15:38 EST Article-I.D.: calgary.1097 Posted: Fri Mar 8 17:15:38 1985 Date-Received: Sun, 10-Mar-85 06:33:27 EST References: <132@heurikon.UUCP> <1094@calgary.UUCP> <1095@calgary.UUCP> Organization: University of Calgary, Calgary, Alberta Lines: 57 Xref: watmath net.unix-wizards:12385 net.sources:2684 > > (Routine posted by me that handles the race problem caused by > > code like alarm(1); pause(); by using self-modifying code > > to destroy the pause system call in the interrupt routine activated > > by the alarm signal.) > Although this solution to the problem may be sound, this method of implementing > it is, er... dumb (to say the least). The following implementation is much > easier to understand, simpler and (Oh wow!) portable: > > > int (*foo)(); > int pause(); > ... > { > ... > /* Point at the pause() call */ > foo = pause; > /* Set up alarm */ > alarm(1); > /* Actually do pause (well, maybe) */ > (*foo)(); > /* Proceed merrily along */ > } > > int null() > {} /* Do nothing function */ > > alarm_signal_handler() > { > foo = null; > } > > > Keith Andrews > U of Calgary, Dept. of CS Unfortunately, this implementation of the solution DOES NOT WORK! One must make sure that no race occurs if the interrupt occurs at ANY time, right up to the instruction which transfers control to the kernel. In the above, it is still possible for the pause procedure to be called before the interrupt but for it to occur before the chmk instruction *within* the the pause procedure is executed. Since a VAX procedure call takes quite a while, this is not all that unlikely. It is also possible that the statement (*foo)(); itself will be compiled into several instructions (it definitely will be on a 68000). There may be a marginally cleaner way of doing this using "indirect system calls", which exist on PDP11 Unices (at least). I see no way of doing it in a machine-independent manner without the appropriate kernel extensions such as 4.2 has. The code-modification technique might still be useful on a 4.2 system if interrupts occur lots of times, making the appropriate sighold (or whatever, I haven't read the manual recently) calls too time-consuming. Radford Neal The University of Calgary