Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!rex!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.unix.questions
Subject: Re: SYS V SIGCLD Handling
Message-ID: <1989Nov29.172533.9794@light.uucp>
Date: 29 Nov 89 17:25:30 GMT
References: <957@sdrc.UUCP> <11656@smoke.BRL.MIL> <870@omen.UUCP> <11667@smoke.BRL.MIL>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Bit Blocks, Inc.
Lines: 27

In article <11667@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <870@omen.UUCP> caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>-In article <11656@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>-:I think the whole notion of signals is broken, but there's not
>-:much point in getting into that..
>-OK, what should replace the notion of signals??
>
>There are lots of possibilities; e.g. CSP.

CSP (Communicating Sequential Processes) to replace signals?
Care to elaborate?

At one time software interrupts seemed like a good replacement
for signals but now I think a cleaner solution is to just use a
separate thread to handle signals.  A `kill()' is a message to
this thread and the signal gets `handled' by receiving this
message.  A `signal()' is also a message to the same thread
indicating what to do when a specific signal is received.  You
wouldn't get nested signals (atleast not easily) but may be that
is a favor!  If you insist on longjumping out of a signal
handler, things get more complicated.  Still, almost all of the
signal functionality can be emulated with threads, messages and
shared variables.

-- Bakul Shah
   bvs@BitBlocks.COM
   ..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs