Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site encore.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!encore!ptw
From: ptw@encore.UUCP (P. Tucker Withington)
Newsgroups: net.unix-wizards,net.sources
Subject: Re: When does ( alarm(1) == alarm(INFINITY) ) ?
Message-ID: <178@encore.UUCP>
Date: Tue, 12-Mar-85 13:52:28 EST
Article-I.D.: encore.178
Posted: Tue Mar 12 13:52:28 1985
Date-Received: Thu, 14-Mar-85 04:38:14 EST
References: <132@heurikon.UUCP> <1094@calgary.UUCP> <1095@calgary.UUCP> <1097@calgary.UUCP>
Reply-To: ptw@encore.UUCP (P. Tucker Withington)
Organization: Encore Computer Corp., Wellesley Hills, MA
Lines: 16
Xref: watmath net.unix-wizards:12423 net.sources:2701
Summary: 

It seems to me that the ill-defined functionality of alarm, signal, and pause
is just a plain, old, *bug* that should be addressed by AT&T and/or the Unix
standards committee rather than hack-fixed.  (Maybe they already did?)

My proposal (2 cent royalty):

The *kernel* should maintain a per-process "wakeup waiting" flag that is
cleared by signal, set when a signal is caught in user mode, and causes pause
to return immediately (as if interrupted) if it is set when a pause is invoked.
I believe this would both eliminate the race/vulnerable condition and stay
within the original intent of the semantics of signals and pause.  (To the
extent that read, write, and wait have similar semantics w.r.t. signals, they
should also use the flag.)

                               o.o      --tucker
                                ~