Interrupted library calls

[Doug Gwyn]

In article <373 at node17.mecazh.UUCP> paul at mecazh.UUCP (Paul Breslaw) writes:
>This is especially so if the signal is allowed to interrupt any old bit of 
>code that might be updating some data structure that is subsequently needed. 
>And this, of course, is what happened when certain Xlib routines were 
>interrupted.
>That leaves 3 - but whose responsibility is it to defend the data in the
>library - the implementor or the user?
>Clearly this is a general problem, but I do not recall seeing anything
>about it on the net.

The relevant properties are reentrancy and noninterruptibility.

These issues were recognized by the various standardization groups.
For example, ANSI C requires that signal() be invokable within any
signal handler, and that a signal handler function terminate only
via return, abort(), exit(), or longjmp().  IEEE 1003.1 adds a
large number of ("system call") functions that are required to be
invokable reentrantly or else block signals during their operation
(so that reentrance is not possible).  The X/Open Portability Guide
adds chroot() to this list and imposes these constraints on abort(),
exit(), and longjmp() (which are therefore hard to implement!).

Note that stdio functions and other similar library functions were
NOT so constrained, in order to avoid paying a run-time penalty on
each use of these heavily-used functions.  However, some vendors of
multiprocessor implementations of UNIX have decided to go ahead and
use semaphores to protect critical regions within such library
functions, in order to prevent the kind of problem you encountered.

Unless the specification of a library function states that it is
safe to abort or reenter it, you the application programmer should
take steps to avoid doing so.