Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!tektronix!cae780!hplabs!hpcea!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: comp.unix.wizards
Subject: Re: No more signals
Message-ID: <5980004@hpfcdc.HP.COM>
Date: Fri, 19-Jun-87 20:48:38 EDT
Article-I.D.: hpfcdc.5980004
Posted: Fri Jun 19 20:48:38 1987
Date-Received: Mon, 22-Jun-87 06:30:52 EDT
References: <48300005@hcx1>
Organization: HP Ft. Collins, Co.
Lines: 19

>I think that making up some sort of 64 bit structure to hold the mask would be 
>a performance hit because the signal mask is checked in critical places. The
>other solution is to overload an existing signal, but this isn't a general
>solution.

I don't think there's much choice.  If you want more than 32 signals you
need to implement a data structure with more than 32 bits to represent
them.  The performance hit can probably be minimized by doing most of
the checking in the (less frequently called) code where data structures
are modified (eg. signals are sent or signal handling/masking is
somehow modified) and then setting a flag that is easily checked on the
common paths.  Of course the 4.[23]BSD signal interface can't survive
such a change, since sigvec, sigsetmask, sigblock, and sigpause (and
sigreturn) all have an int in the interface.  The interface in the
current draft of the IEEE P1003.1 standard used a defined type to avoid
this limitation.

		Bob Lenk
		{ihnp4, hplabs}!hpfcla!rml