Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!uakari.primate.wisc.edu!aplcen!ginosko!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.windows.x
Subject: Re: "Alarm clock" from Xfig
Message-ID: <2459@auspex.auspex.com>
Date: 16 Sep 89 19:40:31 GMT
References: <258@enuxha.eas.asu.edu> <63770001@hpl-opus.HP.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 31

>I had the same error when I compiled it on a HP9000/350.
>The error disappeared when I recompiled it with the -lbsd option.

Sounds like a BSD signal semantics vs. non-BSD signal semantics problem;
in fact, checking "blink.c", that's probably what it is.

The problem is that in the original UNIX from Research, when a signal
was delivered to a process, the signal action reverted to the "default"
action, which was, in most cases, to kill the process - it was the case
for SIGALRM.  Berkeley changed that in 4.2BSD so that the signal handler
wasn't reset, but the signal was "blocked" when the signal was
delivered; the process could explicitly unblock it, and if it didn't it
would get explicitly unblocked when the signal handler returned.

While the BSD behavior is better, it's incompatible, and there's no way
to get the old-style behavior; this means people end up writing programs
assuming the BSD semantics are the only ones you ever get (especially if
they've only worked on BSD systems) and those programs crash and burn on
systems without the BSD semantics.

One fix would be to put

	signal(SIGALRM, blink);

as the first statement in "blink()".  However, since "xfig" already uses
one BSDism, namely "setitimer" to get alarm-clock signals with less than
one second resolution, you might want to just assume that you're running
on a system where you can, somehow, get BSD signal semantics.  Try
seeing whether your system has the "sigvec" call and, if so, use it
instead of "signal" in "blink.c".  If not, check for "sigaction"
instead.