Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!encore!pinocchio!aral
From: aral@pinocchio.Encore.COM (Ziya Aral)
Newsgroups: comp.unix.wizards
Subject: Re: Signals after exec
Message-ID: <5092@xenna.Encore.COM>
Date: 10 Mar 89 05:12:07 GMT
References: <2071@lcuxlm.ATT.COM> <963@ncr-sd.SanDiego.NCR.COM> <5025@xenna.Encore.COM> <986@ncr-sd.SanDiego.NCR.COM>
Sender: news@Encore.COM
Reply-To: aral@pinocchio.UUCP (Ziya Aral)
Distribution: na
Organization: Encore Computer Corp, Marlboro, MA
Lines: 70


In article <986@ncr-sd.SanDiego.NCR.COM> greg@ncr-sd.SanDiego.NCR.COM (Greg Noel) writes:

>Er, no, it doesn't -- but it does bring us back to the initial topic, which
>was, what happens if you have shared signals between two processes, but
>separate address spaces?  How do the semantics of that work out?

I will have to be forgiven because I don't make it to the net every week and am
not entirly familiar with the history of this discussion. I assume that the
original discussion is implied by the subject "Signals after exec".

The nUNIX kernel does not address the propogation of anything across
execs. It basically specifies that whenever a resource is copied (via fork),
it can instead be shared. As far as forks go, there is no semantic problem. A
conventional fork propogates the signal handler by copying the address space of
the parent, including the signal handler, to the child. The only change that
nUNIX adds is that the memory and/or signal resource of the parent may be
shared rather than copied. All possible combinations are legitimate because the
signal handler, whether shared or private, remains visible after the fork. The
only difference in a shared signal resource is that changes made to it by any
one process which uses it impact all processes which share it... i.e. the table
of signal handlers plus some additional state is made sharable. 

When we implemented shared signal handlers, we discussed whether the signal
event itself should be shared (as in MACH). We opted for the more conservative
approach of only sharing handlers as this is much better defined.

The nUNIX prototype also takes a very conservative view of what constitutes a
"resource". Essentially it defines independent resources as only the 
the six classes of resources currently broken out in the user.h header
(i.e. memory, signals, file descriptors, process stats, protection, and
resource control). While it is clear that other process attributes could be
broken out as independently sharable resources and that additional resources
could be easily added (the direction of our current research), this would not
really impact existing semantics.

The reason shared resources do not impact exec is that exec implies a process
transformation in which only some of the original process state is retained.
In particular, it means that a new memory resource, and thus also a new
signal resource must be created. The retention of existing semantics means that
memory sharing stops at an exec. For what is inherited across an exec, instead
of inheriting the the appropriate values of the exec'ing process, the execee
transparently inherits the link to the resource and whether that resource is
shared or not is largely irrelevent. If additional process attributes were to
be made independently sharable resources (for example, interval timers), the
same would apply. If exec semantics were to be changed to allow the inheritance
of more process state, the same answer would again be valid PROVIDED that such
a change did not fundamentally change UNIX semantics.

The propogation of signal handlers across exec() is an entirely different
issue in that it violates the last point above quite apart from the issues
of shared vs private resources. UNIX semantics define signal handlers as mere
user subroutines of arbitrary complexity and execs as chaining operations.
The contradiction that other posters must have mentioned becomes immediately
obvious. There is no way to reconcile the inheritance of signal handlers
without inheriting the image (shared or not) of the exec'ing process
and that is the exact opposite of what an exec is meant to do. Here it is not
even possible to retain part of the original image because there are no
limits on the dependencies of signal handlers. Since the original image AND
its logic disappears, the signal handlers must disappear with it. While it
could be argued that UNIX's address space and its user-level exception handling
are thus too tightly coupled, other solutions would be less general.

It may be possible to exercise a much more restricted form of control over
the exec'ed child by making the sigmask (currently process private in nUNIX)
and some additional signal state into an independently sharable resource but
I have not really thought about it.


Ziya Aral		aral@multimax.encore.com