Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt!ius2.cs.cmu.edu!edw
From: edw@ius2.cs.cmu.edu (Eddie Wyatt)
Newsgroups: comp.unix.wizards
Subject: Re: No more signals
Message-ID: <1207@ius2.cs.cmu.edu>
Date: Thu, 18-Jun-87 10:22:17 EDT
Article-I.D.: ius2.1207
Posted: Thu Jun 18 10:22:17 1987
Date-Received: Tue, 23-Jun-87 01:03:31 EDT
References: <48300005@hcx1>
Organization: Carnegie-Mellon University, CS/RI
Lines: 53

In article <48300005@hcx1>, tomp@hcx1.SSD.HARRIS.COM writes:
> 
> I am trying to implement the SIGWINCH (window size change) signal and ran into
> an interesting problem: no more signals are left. Our kernel is a combination
> of both Berkeley and AT&T. Our machine has a 32 bit word size. The system keeps
> a mask of the signals and checks it in such places as system call entry/exit.
> 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.
> 
> Anyways, has anyone out there ran into (or even thought about) this problem. If
> so, I would like to get ideas about how this problem will be addressed in the
> future. It is going to affect everyone pretty soon as Berkeley only has one
> signal left (AT&T has about 8 left).
> ------------------------------------------------------------------------------
> Tom Peck			"Hurry now. You don't want to be late."
> Harris Computer Systems		"Late? Late for what?"
> 2101 W. Cypress Creek Rd.	"No, late as in 'The Late Arthur Dent' late."
> Ft. Lauderdale, FL. 33309
> uucp: tomp@hcx1.harris.com


  I also find the number of user defined signals provided to be a limitation.
A better exception handling feature would be for the OS to provide generic
signals (up to max(unsigned int) of them).  The idea being to separate
the hardware concept of an interrupt handler from the software concept
of an exception handler (sound a little like Ada?).

   A posibility, that I haven't tried, is to overload an interrupt's meaning.
The task that generates the interrupt must some how provide extra information
to the actual interrupt handler so it can determine the intented meaning of
the interrupt.  After the system interrupt handle has determined the
meaning, it calls the appropriate exception handler.

  Posibilities for pushing extra information around are: 1. if the
task is interrupting itself (kill) then set a global data structure
to indicate the extra information. 2. if the task is interrupting another
task then one could use pipes (yuk), shared memory (shmctl, shmget), or
common files (double yuk).

  This all sounds like a good library facility to provide, hmmmm.

  Another Unix function that I see having problems is "select".  If you
decide to muck around with the kernal and increase the max number of 
file descriptions to more than the number of bits in an integer then
your going to have problems using select to do multiplexing since
it uses an int as a bit mask for the files examined.

-- 
					Eddie Wyatt

e-mail: edw@ius2.cs.cmu.edu