Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!syd
From: syd@DSI.COM (Syd Weinstein)
Newsgroups: comp.unix.aux
Subject: Re: ELM, job control and signals
Message-ID: <1991Apr16.125446.18573@DSI.COM>
Date: 16 Apr 91 12:54:46 GMT
References: <4886@dftsrv.gsfc.nasa.gov> <1991Apr15.185850.3287@panix.uucp>
Reply-To: syd@DSI.COM
Organization: Datacomp Systems, Inc.  Huntingdon Valley, PA
Lines: 19

alexis@panix.uucp (Alexis Rosen) writes:
>>	2. I didn't leave it in the back long enough
>And the winner is... door number 2.
>Based on the message it prints and the fact the it only dies after lengthy
>suspensions, I'm guessing that perhaps it's setting up some sort of signal
>so that it doesn't get too stale? If so then the bug is in how fast it's
>expiring, not that it's expiring at all. Any ideas?
Elm uses a signal every timeout seconds to refresh the screen if new messages
came in.  A/UX apparently doesn't like it if a bg'd task takes an alarm
clock interrupt.  Thus when it wakes up it gets the error.  This is not
true of other UNIX OS's that support job control.  They just stack the
alarm wakeup until after resumption of the task.

Looks like a problem with A/UX to me.
-- 
=====================================================================
Sydney S. Weinstein, CDP, CCP                   Elm Coordinator
Datacomp Systems, Inc.                          Voice: (215) 947-9900
syd@DSI.COM or dsinc!syd                        FAX:   (215) 938-0235