Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!ux1.cso.uiuc.edu!tank!rtp1
From: rtp1@tank.uchicago.edu (raymond thomas pierrehumbert)
Newsgroups: comp.sys.apollo
Subject: GPR borrow mode display hang
Keywords: GPR
Message-ID: <7639@tank.uchicago.edu>
Date: 14 Feb 90 05:40:36 GMT
Organization: University of Chicago
Lines: 21

I have just started doing some graphics hacking on my DN10000 with
8-plane AT bus display.  I am using GPR, for performance reasons and
because that's all I've got now.  Generally speaking, I'm quite
impressed with GPR.  It is a powerful and quite simple interface,
very much in the spirit of the Mac's Quickdraw toolbox calls.
    My question is this.  I would like to write some routines that
use the display in "borrow" mode, i.e. take over the whole display.
My worry is, what if one of my students uses these in a program, but
gets stuck in a loop, or otherwise forgets to have the program 
terminate GPR and give back the display?  It would seem then that
I would really be stuck, as ctrl-c seems to be ignored in this 
situation (or is it?), and I can't even shut down and reboot without
getting at the display manager.  I suppose I could log in as the
student over the network (if inetd doesn't crash) and kill the job
that way, but sometimes I've had problems with kill failing because
of some incorrect recognition of ownership of the process.  I can't
log in as root over the net (because I have left things that way for
security) and the sio lines are not currently activated.
     Are these concerns just vapor?  Is there after all some 
reliable way to get back the DM in these circumstances?
.