Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!dce
From: dce@smsc.sony.com (David Elliott)
Newsgroups: comp.windows.x
Subject: Re: What is the error "alarm clock"?
Message-ID: <1991Apr18.144948.18811@smsc.sony.com>
Date: 18 Apr 91 14:49:48 GMT
References: <1991Apr16.182428.15148@elroy.jpl.nasa.gov> <1991Apr17.143023.21254@batcomputer.tn.cornell.edu>
Sender: dce@smsc.sony.com (David Elliott)
Distribution: na
Organization: Sony Microsystems, San Jose, CA
Lines: 26


In article <1991Apr17.143023.21254@batcomputer.tn.cornell.edu>, gdykes@theory.tn.cornell.edu (Gene Dykes) writes:
|> In article <1991Apr16.182428.15148@elroy.jpl.nasa.gov> pjs@euclid.jpl.nasa.gov writes:
|> >We're getting X applications terminated at random times by
|> >a cryptic error message, "alarm clock".
|> 
|> I've seen this a lot, too.  My analysis may be wrong, but it appears
|> that on HPUX, alarms are not automatically reset, whereas they are on
|> other operating systems.  Seems awfully strange.  The solution, which
|> has always worked for me, is to go into the function that is called
|> for an alarm, and set another alarm there.

I'm afraid this is generally true for System V and System V-based
systems.  (I seem to recall that V7 did it this way, but it's been
a long time.)  In SVR4, you can use sigset() instead of signal(),
but I prefer not to (can you say -ljobs?).

I'd say it's just as strange to have signals stick, especially an
alarm signal.  At the very least, you should have to call snooze()
to make it come back later ;-).

-- 
...David Elliott
...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce
...(408)944-4073
..."Once a head-crusher, always a head-crusher" - Mark M.