Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!husc6!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.unix-wizards
Subject: Re: Subtle bug in fflush and fix
Message-ID: <2065@brl-smoke.ARPA>
Date: Thu, 10-Jul-86 06:46:56 EDT
Article-I.D.: brl-smok.2065
Posted: Thu Jul 10 06:46:56 1986
Date-Received: Sat, 12-Jul-86 03:20:43 EDT
References: <1781@milano.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <1781@milano.UUCP> peterson@milano.UUCP writes:
>The stdio package does not seem to properly account for some effects
>of signals.

This is a tremendous understatement.  Use of signals is so
fraught with peril that X3J11 seriously considered guaranteeing
absolutely nothing whatsoever about what a signal handler can
do.  I personally can't even guarantee that a signal handler
function is entered successfully on most machine architectures.

The problems are not as well known as they should be.  Signals
can impact the design of much of the C library.  AT&T reworked
the standard I/O routines in an attempt to permit the use of
printf() in a signal handler, but they didn't get it quite right
because it is NOT POSSIBLE to get it right, at least not without
severe performance impact.  Many experienced UNIX system
programmers avoid using signals for anything other than
	(1) job control, on Berkeley-like systems;
	(2) synchronous notification of state changes, such
		as SIGWINCH;
	(3) a means of requesting termination of a process.
Certainly they should not be used for IPC.

This is not a criticism of Peterson's bug fixes.  That just
prompted me to mention this in case there is anyone who needs
to be warned.