Re: ex1 vs. ex

[cld@xxxxxxxx (Carl Distefano)]

Reply to note from Harry Binswanger  Sun, 14 Nov
2004 11:48:00 -0500

Harry:

> Any reason not to use ? Any problems with the program
> calling U2 routines?

Be judicious with EX1, especially in child routines, or subroutines,
and especially in routines that call Jumbo U2 frames. If the parent
routine is located entirely in the "transient" Save/Get range 01-99,
you're probably OK. But if the parent routine uses any "permanent"
(100-1999) or "ordinary" (A-Z, 0-9) S/Gs -- values that stay memory-
resident after the program terminates -- you're asking for trouble.
At the very least, you'll be cluttering memory with these permanent
values, which the parent routine would have (or should have) cleared
had it been allowed to terminate normally. But there's also the
danger that other XPL programs, expecting to find these permanent
slots empty, will fail or misbehave if one or more of these S/Gs
contain pre-existing values.

Most Jumbo U2 routines are located in the transient range 01-99.
BUT -- but -- many of our routines use special-purpose S/Gs in the
600-799 range, which is reserved to the Jumbo U2 (documented in
README.1ST, in the XYWEBnnn.ZIP file). U2 is meticulous about
cleaning up after itself in this reserved range: Nothing is left
behind in memory that isn't absolutely required to be there. But if
your personal subroutines call our U2 routines and then terminate
early with EX1, this garbage collection may not happen, with
possible unexpected results as explained above. So, if you do call
a U2 frame as a child process, be aware of the S/G ranges used by
that frame -- and of the ranges used by all of the frames called by
that frame, and by all of the frames called by those frames, and so
on, down to the very last generation of child processes -- a non-
trivial exercise, because U2 is modular, with frames calling other
frames calling other frames all over the place. If you absolutely
MUST use EX1 in your routine, position the EX1 so that all Jumbo U2
frames have terminated by the time EX1 is encountered.

Or, better stilll, avoid EX1 altogether. It's usually avoidable.
For example...

> I want to do this kind of termination when there is an error
> condition in running the daughter program--it will make it
> easier to add ad hoc displays into the code.

I don't know what you mean by "ad hoc displays". Error messages?
And are you talking about temporary code, for purposes of debugging,
or permanent features of the program?

Let's assume you mean error reporting. If the child routine
encounters an error condition, you want to report it to the user and
end the entire program in an orderly way. Instead of EX1 in the
child, set a return code, exit normally () to the parent, and
report the error _in the parent routine_, then terminate the parent.
So the child would look like this (here, the error code is in S/G
01):

;*; return code 0 if operation is normal
[do something] ;*;
;*; return code 1
;*; return code 2
;*; return code 3
etc.

And the parent like this:

.. JM 2.childQ2 ;*; call to child process
==1>;*;
==2>;*;
==3>;*;
else child succeeded, so move on....

There are SO many demands on parents these days that it's tempting
to plunk an EX1 in front of the child, just to shut it up. But you
know, Harry, and I know, that that's no way to raise a child
process. Spend some quality time with your daughter and son
routines, train them to confide in the parent if problems arise, and
put the solutions where they belong, with the parent that caused the
problem by deciding to have child processes in the first place!
There's a lot riding on this, Harry. It's not just your future,
it's all our futures. So, please...

--
Carl Distefano
cld@xxxxxxxx