Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!cscnj!kevin
From: kevin@cscnj (Kevin Walsh)
Newsgroups: comp.unix.internals
Subject: alarm () expiring too soon
Message-ID: <1990Nov14.172636.5274@cscnj>
Date: 14 Nov 90 17:26:36 GMT
Distribution: na
Organization: Computer Sciences Corporation, NJ (CSD)
Lines: 56

I am working with an application which runs on Amdahl's UTS 1.2, which is
their port of UNIX system V. In this application there are numerous instances
where a blocking read is initiated on a message queue using "msgrcv" and a
time-out is implemented using the alarm () and signal () functions. The typical
scenario is like this:

msg_timeout ()
{
    timed_out = 1;
}
	.
	.
	.

	timed_out = 0;
	signal (SIGALRM, msg_timeout);
	alarm (5);

	msgrcv (q_id, buffer_addr, q_size, 0, 0);

	alarm(0);
	signal (SIGALRM, SIG_IGN);

	if (timed_out) {
	/* handling for time-outs */
	}
	.
	.
	.

Most of the time, everything works as expected; if the timer expires the
blocking read is interrupted and the alarm clock is cleared, otherwise an
incoming message is read and the blocking read returns and again the alarm 
clock is cleared. In both cases the code check if the time-out flag has been
set by the function handling the SIGALRM signal. 

The problem is that sometimes (an not always in the same module), the alarm
clock appears to expire at the instant it is being set. When this happens,
the alarm expires before the blocking read is even initiated. The result is
that the call to "msgrcv" block with no time-out -- until a message is received.
We have verified that this is happening by setting calling time() at various 
points during this processing and printing the timestamps when the alarm is
set, when the signal-handling function is entered, and when the "msgrcv" 
function has returned. The timestamps printed are all the same time, to the
second.

I have posted this in the hope that someone else out there may have had or 
heard of this type of problem. Any comments or proposed solutions would be
appreciated. 

Thanks, Kevin

-- 
---------
Kevin Walsh  Computer Sciences Corporation  Piscataway, NJ  08854
..!rutgers.rutgers.edu!cscnj!kevin