Interrupted library calls

[Barry Margolin]

In article <373 at node17.mecazh.UUCP> paul at mecazh.UUCP (Paul Breslaw) writes:
>That leaves 3 - but whose responsibility is it to defend the data in the
>library - the implementor or the user?

I think it *should* be the implementor's responsibility.  However, given
that most library implementors don't do so, it is effectively the user's
responsibility.

The best situation would be for library implementors to protect their
critical regions.  Next best would be for them to document which routines
have critical regions, so that the caller can bracket calls to those
routines with signal masks (unfortunately, this means that signals are
masked for longer than they need to -- the critical region may be a small
part of the library routine).  Every routine for which such documentation
doesn't exist must be assumed to have critical data, and cannot be aborted.

In addition to maintaining consistent data structures, it's also necessary
for library routines to clean up after themselves.  For instance, if a
subroutine opens and closes a file, that file should always be closed when
the subroutine is exited.  I'm primarily a Lisp programmer, and C and Unix
(among others) are missing a really important facility for systems
programming: UNWIND-PROTECT.  This is a mechanism for insisting that a
particular piece of code be run upon exiting a context, no matter how that
context is exited (either by returning or by non-local transfer).  When I
was a Multics programmer we had a similar thing; a handler could be written
for the "cleanup" condition, and the handler is run when a frame is exited
via non-local transfer.  In C it's possible to implement something like
this using a setjmp/longjmp protocol, but it only works with cooperating
routines; library routines won't obey the protocol, though.

--
Barry Margolin, Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar