Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!mulga!ausmelb!jal
From: jal@ausmelb.OZ (Joe Longo)
Newsgroups: comp.unix.wizards
Subject: Re: signals like interrupts?
Message-ID: <326@ausmelb.OZ>
Date: Mon, 20-Jul-87 22:29:30 EDT
Article-I.D.: ausmelb.326
Posted: Mon Jul 20 22:29:30 1987
Date-Received: Wed, 22-Jul-87 06:37:01 EDT
References: <17691@cmcl2.NYU.EDU>
Reply-To: jal@ausmelb.UUCP (Joe Longo)
Organization: Austec International Limited, Melbourne
Lines: 59


On the subject of signal handling under UNIX: We've recently been
considering a scheme that allows multiple handlers to be called for every
signal. This allows independent library routines to process signals, such
as SIGINT, without knowing of, or interfering with, other signal handlers.

E.g.: an I/O library might want to catch signals so that it can clean up its
files, while a screen library might want to catch signals to
reposition the cursor in a known place.

The method used would be relatively simple. We would create a function
that would look like:
	
	int usignal(signo, action, function)
	int         signo;
	int                action;
	int                       (*function)();

where
	signo      is the signal number,
	action     is either "add to queue" or "delete from queue".
	function   is a pointer to the user function that's added or removed.

When a signal comes in, each of the functions requested is called in turn.
[There are other details I won't go into (e.g., rules on
returning from the function; default action on signals; etc..)]

The advantage to this approach is that it eliminates the excessive system
calls involved in setting your own handler, saving the old one, then
reseting the old handler every time the library function in called:

	oldfunc = signal(signo, newfunc);
	
	signal(signo, oldfunc);

This represents a significant overhead in the case of numerous
calls to the library function.

Question: Is there a "standard" or preferred approach to this problem?
	  I can't believe I'm the first or only person to have tried to
	  solve it. If so, could someone suggest the preferred approach?

If others have done it, can they tell me what "traps"
(no pun intended) they know of with this type of scheme?

Thanks.
-- 
 ---------------------------------------------- -----=-----
Regards,					----===----
						---=====---
Joe Longo,					--=== ===--
Melbourne.					-==== ====-
						a u s t e c

					ACS:  jal@ausmelb.oz
Austec International Ltd,		UUCP: ...!seismo!munnari!ausmelb!jal
344 St Kilda Rd,			ARPA: jal%ausmelb.oz.au
Melbourne, Victoria, 3004.		Fax: 699 9870	Telex: 38559
AUSTRALIA				Phone: +61 3 699 4511
D