Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!lll-winken!gauss.llnl.gov!casey
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.unix.wizards
Subject: Re: Interrupted library calls
Keywords: Xlib, library, signals, longjmp
Message-ID: <44985@lll-winken.LLNL.GOV>
Date: 18 Jan 90 23:13:50 GMT
References: <373@node17.mecazh.UUCP> <32968@news.Think.COM>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: casey@gauss.llnl.gov.UUCP (Casey Leedom)
Organization: Lawrence Livermore National Laboratory
Lines: 48

| From: paul@mecazh.UUCP (Paul Breslaw)
| 
| [Mentions three possibilities to deal with interrupted library calls
| leaving corrupted data structures, etc. behind when the signal catching
| routine decides to head off elsewhere's via a longjmp(3).]

  You missed a couple of possibilities Paul.  Barry Margolin mentions one
which is by far the best [in my mind], but would require:

    1.	The addition on an ``unwind-protect'' code pointer to the C stack
	frame.

    2.	Modification of the C function entry and exit code to allocate
	and initialize the unwind-protect pointer to NULL on entry and
	execute the pointed to code if the unwind-protect pointer is
	non-NULL on exit.

    3.	A mechanism to manipulate this pointer (probably just a couple of
	macros.)

    4.	A change in the semantics of longjmp(3) to indicate that it calls
	each of the non-NULL unwind-protect code segments as it unwinds
	the stack

Perhaps Barry will explain what happens when an interrupt happens while
unwind-protect code is being executed ...  The issue of what happens with
respect to inlined functions is also interesting.  Perhaps the presence of
unwind-protect pointer manipulation should simply prevent a function from
being inlined ...

  Another possibility which is perhaps a little more practical, given the
inertia of language standards, is to implement the above outside of the
regular C stack by providing a separate unwind-protect stack and routines
to manipulate it.  This would require large amounts of standardization
effort and recoding to use it, but wouldn't require changing anything in
the ANSI C standard.

  On a final note, work is now being done to look into the possibility of
moving most of the signal facilities into user space.  This would
essentially reduce the expence of calling setsigvec, sigblock, etc. to a
function call instead of a system call.  The penalty would be that *all*
signals would be delivered from the kernel to the signal dispatcher in
user space even if they were blocked or ignored.  It's expected that
overall this should be a major win for most applications.  If it is
implemented, then the thought of putting signal blocking around critical
sections in library routines isn't cause for quite so much queasiness ..

Casey