rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) (02/14/90)
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?
.krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (02/14/90)
Unless you explicity disable the system's quit character (usually control-Q in an AEGIS environment, and I think also in a BSD4.3 environment) you can always quit out of a program back to the display manager. The inetd daemon doesn't usually crash, and you can also use /com/crp to log in remotely (requires that the node be running mbx_helper and server_process_manager (spm) -- but they also are fairly reliable). If you can't login as root over the net for security purposes, you can always do a remote login as yourself and then "su" or "login" to root once you already have the remote connection. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
oj@apollo.HP.COM (Ellis Oliver Jones) (02/17/90)
In article <7639@tank.uchicago.edu> rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes: >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? Just Like Real Aegis :-) , press <ctrl>-Q . <ctrl>-Q is the default quit character for borrow-mode. >It would seem then that I would really be stuck, as >ctrl-c seems to be ignored in this situation (or is it?) You can change the default quit character with gpr_$set_quit_event. For example, to set the quit character to ^C (3), try #include <apollo/base.h> #include <apollo/gpr.h> char quitchar = 3; status_$t sts; ... gpr_$init ( gpr_$borrow...); ... gpr_$set_quit_event ( gpr_$keystroke, quitchar, &sts); The problem with this, obviously, is that your students may put it in some programs and not in others, so you'll have to guess what the quit character is when you get a hung borrow-mode program. The other problem is that you can disable quits altogether with this call, and that's definitely bad (unless you're writing a very robust piece of software). >I can't even shut down and reboot without >getting at the display manager. Won't the DM respond to the shutdown switch on the front of the 10K box even when you're in borrow mode? >I suppose I could log in as the >student over the network (if inetd doesn't crash) and kill the job Yes, or you could run spm and crp -on to the node and do the same thing. If you do % su # crp -on //offending_node -me you'll have root privs on the offending node and process-ownership won't be an issue. >Are these concerns just vapor? I've heard lots of arguments about why borrow-mode programs are undesirable, but I haven't heard of this particular issue as a serious problem before. /Ollie Jones (speaking for myself, not necessarily for HP Apollo Systems Division).