montnaro@sprite.uucp (Skip Montanaro) (06/19/87)
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 73andrew@lemming.gwd.tek.com (Andrew Klossner) (06/25/87)
From: andrew@lemming.gwd.tek.com (Andrew Klossner)
"My question is, has the POSIX group discussed any alternatives
to the signal facility?"
The answer is no. The charter of a standards group is to codify
existing practice, not to invent something new. All too often this
charter is violated, to the detriment of the community.
[ Unfortunately, it's not always easy to stay on one side of the line.
The signal facilities in POSIX at the moment are not quite like those
in any existing system, i.e., they are to some extent an invention.
This was necessary in order to produce something that was implementable
in the context of the various existing systems. -mod ]
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]
Volume-Number: Volume 11, Number 81