Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcsun!hp4nl!nikhefh!t68
From: t68@nikhefh.nikhef.nl (Jos Vermaseren)
Newsgroups: comp.sys.atari.st
Subject: Re: Changing Rez:  What we _really_ want to know
Message-ID: <715@nikhefh.nikhef.nl>
Date: 9 Jan 90 10:21:21 GMT
References: <8912301917.AA19200@TIS.COM> <2009@sbsvax.UUCP> <1929@atari.UUCP>
Reply-To: t68@nikhefh.nikhef.nl (Jos Vermaseren)
Organization: Nikhef-H, Amsterdam (the Netherlands).
Lines: 34


In a previous article A. Pratt comments about that the terminate
vector should only be used to terminate. There are exceptions to
this!!!!!!!!
A good editor that runs from a good shell (a shell which has installed
an emergency break, so that a child process can be stopped) should
not be killable. See for instance vi under UNIX. Ctrl-C won't kill
it.
The problem is that Atari has no proper way to kill a child process,
so kludge methods has to be made to make GEMDOS believe that the
child itself asks for termination. After that there are some
children that don't want to be killed. This can be done rather
easily. Make a routine and install it as termvector. The whole
routine reads:
	unlk a6
	rts
This causes a return from the term routine in GEMDOS before
it starts cleaning up (I can hear Allan already.....).
Of course it would be much better if Atari would come up with
some standards on how to do this in a conventional way, together
with a proper way to kill processes that don't produce output
via GEMDOS. Using the environment seems to clumsy because it
has to be checked before the kill command (Pterm) is given,
which means that the environment has to be checked from an interrupt
routine. That isn't nice.
A reserved variable in the low memory globals would be better.
It the variable is zero, the process may be killed.
A second variable/flag could indicate whether the Atari is going
to kill a process safely (for instance only when the PC points to
an address inside the memory of the process).
Sounds like some work for Allan to make up a good scheme.

Jos Vermaseren
t68@nikhefh.nikhef.nl