ELM, job control and signals

John Coolidge coolidge at cs.uiuc.edu
Wed Apr 17 05:33:09 AEST 1991


syd at DSI.COM (Syd Weinstein) writes:
>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.

Here's what I think is going on: A/UX, by default, uses SYSV style
signals (signal handler reset to default every time a signal is called).
This means the first timeout signal works and the rest are punted. Note
that elm doesn't seem to do the right thing with this even in the
absence of job control; I've had elm on A/UX die with 'alarm clock' if I
just leave it running for a while. With job control, things just get
worse. Now even if you try to do the right SYSV thing and reenable the
signal handler, if you're TSTP'd the signal is enqueued and doesn't hit
the handler until things are CONT'd. By that point it seems to become
likely that the previously mentioned mishandling kicks in and everything
fails.

If, however, you tell A/UX to use BSD signal semantics by calling
set42sig() as the first thing in main() the problem seems to go away (it
did for me; I can leave elm in the background for a day and then resume
it with no ill effects). Somehow elm is becoming confused and not
handling SYSV signal semantics properly...

--John

--------------------------------------------------------------------------
John L. Coolidge     Internet:coolidge at cs.uiuc.edu   UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1991 John L. Coolidge. Copying allowed if (and only if) attributed.
You may redistribute this article if and only if your recipients may as well.



More information about the Comp.unix.aux mailing list