Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!ncar!boulder!ccncsu!ncr-fc!ncr-sd!greg
From: greg@ncr-sd.SanDiego.NCR.COM (Greg Noel)
Newsgroups: comp.unix.wizards
Subject: Re: Signals after exec
Message-ID: <941@ncr-sd.SanDiego.NCR.COM>
Date: 23 Feb 89 20:46:04 GMT
References: <1187@csd4.milw.wisc.edu> <9687@smoke.BRL.MIL> <90896@sun.uucp>
Distribution: na
Organization: NCR Corporation, Rancho Bernardo
Lines: 24

In article <1187@csd4.milw.wisc.edu> jd@csd4.milw.wisc.edu
(James R Drinkwater) writes:
>Can you think of examples in which you would like to keep a signal handler
>installed across exec?

In other articles, Larry McVoy and other folks argue that this doesn't
make much sense, since a signal handler is part of your address space,
which is lost upon an exec.

This was my initial reaction, too, but then I remembered a paper at the
Winter USENIX conference that presented something called "variable-weight
processes."  This paper very neatly unified the model of a thread and a
process by defining groups of resources, including memory map, file
descriptors, signals, and other resources, that could be shared between
a parent and child thread.  At the one extreme, sharing everything, this
gives a "traditional" thread, while at the other extreme, sharing nothing,
this gives a "traditional" (heavy-weight) process.  In between are some
interesting options, including the possibility of sharing signals, but
not sharing an address map.  If anybody knows how this kind of semantics
was worked out (my copy of the Proceedings isn't here, and my fuzzy memory
of the paper itself says that they didn't discuss it), I'd be interesting
in hearing about it.
-- 
-- Greg Noel, NCR Rancho Bernardo   Greg.Noel@SanDiego.NCR.COM  or  greg@ncr-sd