Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!zaphod.mps.ohio-state.edu!usc!snorkelwacker!mit-eddie!apollo!oj From: oj@apollo.HP.COM (Ellis Oliver Jones) Newsgroups: comp.sys.apollo Subject: Re: GPR borrow mode display hang Summary: -Q Keywords: GPR, quit Message-ID: <48ae3e15.20b6d@apollo.HP.COM> Date: 16 Feb 90 16:27:00 GMT References: <7639@tank.uchicago.edu> Sender: root@apollo.HP.COM Reply-To: oj@apollo.hp.com Organization: Apollo Computer, Chelmsford, MA Lines: 52 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 -Q . -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 #include 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).