Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!sgi!shinobu!odin!ramoth.esd.sgi.com!msc
From: msc@ramoth.esd.sgi.com (Mark Callow)
Newsgroups: comp.sys.sgi
Subject: Re: Crashing the window manager ( Yet another way to do it)
Message-ID: <3522@odin.SGI.COM>
Date: 2 Feb 90 19:22:19 GMT
References: <6619@ubc-cs.UUCP>
Sender: news@odin.SGI.COM
Reply-To: msc@sgi.com
Organization: Silicon Graphics Inc., Entry Systems Division
Lines: 24

In article <6619@ubc-cs.UUCP>, buchanan@cs.ubc.ca (John Buchanan) writes:
> 
> The recent postings about programs that crash the window server has prompted
> me to try to produce the following gem.  We are running an application which
> requires interrupt handling.  The problem is that trying to do some graphics
> after an interrupt (SIGINT) has occurred crashes the machine.  The original
> program showed this problem in a somewhat non deterministic fashion, the 
> program that follows crashes the machine after the first interrupt.

This is no suprise.  If you are busy sending graphics down the pipe then
asre interrupted by a signal and start sending unrelated and unexpected
graphics down the pipe you are bound to crash it.  Imagine you and
inside a bgnpolygon(), endpolygon() pair when you are interrupted
and your interrupt routine does a rectf or a winset.

The correct way to deal with signals is to have the signal handlers
set flags which your main loop checks regularly at times known to
be safe.  This is a fairly common UNIX coding practice (especially with
System V signals) regardless of graphics.
--
From the TARDIS of Mark Callow
msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc
"There is much virtue in a window.  It is to a human being as a frame is to
a painting, as a proscenium to a play.  It strongly defines its content."