Xref: utzoo comp.unix.internals:1961 comp.unix.wizards:23967
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!lamont!cats
From: cats@lamont.ldgo.columbia.edu (catherine susch)
Newsgroups: comp.unix.internals,comp.unix.wizards
Subject: BSD vs. Sys V alarm and SIGALRM PROBLEMS!
Keywords: A Bug or not a Bug?
Message-ID: <3313@lamont.ldgo.columbia.edu>
Date: 5 Feb 91 15:46:27 GMT
Organization: Lamont-Doherty Geological Observatory N.Y.
Lines: 111



	We believe that we've discovered a problem/bug with 
	the alarm(3) function and signal(2). Give us your 
	feedback if you	think otherwise, because we think 
	that this is a major problem that needs fixing. 

HERE IT IS:

	We've been trying  to write a timeout  procedure so  that
	if the application  is  waiting  for input  and  the user 
	decides to  take a nap,  beep at him to  type  something,
	and if he doesn't, then exit.

	The system we're using is SunOS 4.0.3  and  the application
	is written using AT&T system 5 curses.
	
	In SunOS 3.5 we used the following test code fragment which 
	will give the desired results:



------------------------------------------------------------------------
	#include <stdio.h>
	#include <signal.h>
	#include <errno.h>
	#include <sys/time.h>

	void	new_alarm();
	void	last_alarm();
	void	bad();

	main()
	{
		int inp;

	/* start alarm and wait for input	*/
		alarm(10); 
		signal(SIGALRM, new_alarm);   
		printf("waiting for input\n");
		inp = getchar();

	/* If input was recieved you should get here	*/

		printf("got input\n bye\n");
		signal(SIGALRM, SIG_IGN);
		exit(0);
}

void	new_alarm()
{
	/* start a new alarm and set a new handler for SIGALRM to 
	   quit if still no input received			*/

	alarm(20); 
	signal(SIGALRM, last_alarm);
	printf("alarm has sounded and new alarm is set\n");
}

void	last_alarm()
{
	printf("no input recieved, exiting program\n");
	exit(-1);
}
------------------------------------------------------------------


   Under all BSD versions it also works the same as SunOS 3.5.
   Under SunOS 4.0.3 and 4.1.1, however, this routine has very different
   results:
	
	The signal call

		signal(SIGALRM, last_alarm),

	inside the handler new_alarm(), never gets set and thus
	the program never gets to last_alarm().  It acts  as if 
	input was received when it wasn't.

	When the routine is incorporated  into an  application  with
	cursesV  calls, once an alarm sounds, it goes into new_alarm() and
	returns without resetting either signal or alarm. This causes it
	to call new_alarm over and over again until input is received.
	
   So here's our question:

		Is this a bug? 

		Has anyone ever encountered this?

		WHAT IS REALLY SUPPOSED TO HAPPEN UNDER SYSTEM 5???????

		Furthermore, is anyone aware of a workaround?

	Please email responses, since we are so preoccupied with
	this problem we may have trouble reading this newsgroup.
	I will post a summary if there is interest.


Cat


________________________________________________________________________________
 	 ______     ___      _________     | 
 	/          /   \         /         |	Catherine Ann Teresa Susch
       /	  /     \       /	   |	Lamont-Doherty Geo. Observatory
      /		 /_______\     /	   |	of Columbia University
     /_______   /         \   /    __	   |	Palisades,N.Y. 10964  USA
				  /__	   |    
				  __/	   |	cats@lamont.ldgo.columbia.edu
___________________________________________|____________________________________