Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Universal OS (was Re: Survey of architectures)
Message-ID: <7788@brl-smoke.ARPA>
Date: 28 Apr 88 20:00:18 GMT
References: <50825@sun.uucp> <670016@hpclscu.HP.COM> <51046@sun.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <51046@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
>The *only* problem is that the ANSI C signal mechanism (which will
>presumably, once ANSI C is adopted, spread its influence to the POSIX signal
>mechanism) demands that signal handlers take only one argument.

There is no logical requirement that signal handlers registered via
sigaction() (new form of sigvec()) and those registered via signal()
must have the same interface, although it is easier to implement if
they do.  There are also other ways of obtaining extended information
than by passing it as arguments to the signal handler function.  I
can think of two obvious ones and there are probably others.

It is not ANSI C that introduced the single-argument signal handler;
that was existing practice everywhere until one day Berkeley decided
to change it on their systems.  Unfortunately Berkeley did not address
the portability issues when they made the change, thereby introducing
an unnecessary complication into what was to that point a simple
mechanism.  The whole signal approach is a botch anyhow; complicating
it without fixing it seems like a counterproductive direction.