pjs@euclid.jpl.nasa.gov (Peter Scott) (04/17/91)
We're getting X applications terminated at random times by a cryptic error message, "alarm clock". I thought I had seen a Q&A go by about this on here a few months ago but I couldn't find it in our current news spool. Any info, please let me know. This is on an HP Apollo Series 400 running mwm. -- This is news. This is your | Peter Scott, NASA/JPL/Caltech brain on news. Any questions? | (pjs@euclid.jpl.nasa.gov)
gdykes@theory.tn.cornell.edu (Gene Dykes) (04/17/91)
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". > >Any info, please let me know. This is on an HP Apollo Series 400 >running mwm. 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.e., what happens is that the first alarm signal is handled properly, but then the signal handler is inactivated, so that when the second alarm signal occurs, since no application code handles it, the operating system gets it and aborts the program...) -- Gene Dykes, gdykes@theory.tn.cornell.edu
dce@smsc.sony.com (David Elliott) (04/18/91)
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.
guy@auspex.auspex.com (Guy Harris) (04/21/91)
>(I seem to recall that V7 did it this way, It did. >In SVR4, you can use sigset() instead of signal(), but I prefer not to >(can you say -ljobs?). In SVR*3* you can use "sigset()". In SVR4 you can do so also, but you can also use "sigaction()" and be done with it ("sigaction()" being the POSIX flavor of 4.2BSD-style signals).
darrylo@hpnmdla.hp.com (Darryl Okahata) (04/22/91)
In comp.windows.x, 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. This is a difference between BSD and SYSV signal-handling semantics (read: it's supposed to work this way -- it is *NOT* a bug). If you want to get BSD signal-handling semantics under HP-UX, link your program with -lBSD. -- Darryl Okahata UUCP: {hplabs!, hpcea!, hpfcla!} hpnmd!darrylo Internet: darrylo%hpnmd@relay.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion or policy of Hewlett-Packard or of the little green men that have been following him all day.