SYS V SIGCLD Handling

[Bakul Shah]

In article <11667 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <870 at omen.UUCP> caf at omen.UUCP (Chuck Forsberg WA7KGX) writes:
>-In article <11656 at smoke.BRL.MIL> gwyn at 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 at BitBlocks.COM
   ..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs