Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: montnaro@sprite.uucp (Skip Montanaro)
Newsgroups: comp.std.unix
Subject: Replacement for signals in POSIX?
Message-ID: <8300@ut-sally.UUCP>
Date: Thu, 18-Jun-87 21:09:02 EDT
Article-I.D.: ut-sally.8300
Posted: Thu Jun 18 21:09:02 1987
Date-Received: Mon, 22-Jun-87 02:12:11 EDT
Sender: std-unix@ut-sally.UUCP
Reply-To: montnaro@sprite.uucp (Skip Montanaro)
Organization: General Electric CRD, Schenectady, NY
Lines: 24
Approved: jsq@sally.utexas.edu (Moderator, John Quarterman)
Summary: Is there any such beast?

From: montnaro@sprite.uucp (Skip Montanaro)

Perhaps this has been discussed before, but I've only recently begun
reading this group.

At the recent USENIX conference in Phoenix the issue of signal
handling came up in relation to the MACH kernel. It seems that signals
and threads (or lightweight processes, if you will) don't fit together
very well. If you think about it for a bit, it's hard to decide which
thread should catch a signal: the active thread? the one that set the
signal? some designated signal catcher? The MACH types have hacked
something together. (I think they decided the active thread would
catch it, but don't quote me.)

My question is, has the POSIX group discussed any alternatives to the
signal facility?

Mail me your replies. I'll summarize if there's any interest.

         Skip|  ARPA:      montanaro@ge-crd.arpa
    Montanaro|  UUCP:      montanaro@desdemona.steinmetz.ge.com
(518)387-7312|  GE DECnet: advax::"montanaro@desdemona.steinmetz.ge.com"

Volume-Number: Volume 11, Number 73