Using ATC to abort code written in Fortran

Using ATC to abort code written in Fortran

[Duncan Sands]

I have a heavy calculation to do which may have to be aborted in the
middle,
using ATC.  Thus

select
   A.Trigger;
then abort
   Huge_Calculation;
end select;

Most of the Huge_Calculation is performed by a numerical library written

in Fortran.  I am worried that ATC may not work correctly if the abort
comes
while in the Fortran code.  Does anyone have any idea?

I can see two kinds of potential problems.  The first comes from how the
fortran
code is written.  For example, if it stores information in global
variables then these
may be left corrupted after ATC.  I'm not so worried by this, because I
can check
the code and do some rewriting if necessary.  I am more worried about
the second
kind of potential problem: will ATC trash memory etc because the code
produced
by the fortran compiler is not compatible with ATC?  I've no idea how
ATC is
implemented, so I've no idea if there could really be code compatibility
problems
or not.  Perhaps someone out there has some experience with this kind of
thing...

I am using g77 (egcs version) for compiling the fortran and GNAT 3.12p
for the
Ada.

Thanks for your help,

Duncan Sands.

PS: Of course, I could wrap the Fortran code up in a protected object,
and exploit the abort deferred property of protected objects to avoid
having the abort come during execution of the Fortran code.  But since
it is the Fortran part that is likely to need to be aborted (because it
can take a long time to complete), this is not very satisfactory.

Re: Using ATC to abort code written in Fortran

[Tucker Taft]

Duncan Sands wrote:
> 
> I have a heavy calculation to do which may have to be aborted in the
> middle,
> using ATC.  Thus
> 
> select
>    A.Trigger;
> then abort
>    Huge_Calculation;
> end select;
> 
> Most of the Huge_Calculation is performed by a numerical library written
> 
> in Fortran.  I am worried that ATC may not work correctly if the abort
> comes
> while in the Fortran code.  Does anyone have any idea?

I suspect it will work, but you need to check with the compiler vendor.

> I can see two kinds of potential problems.  The first comes from how the
> fortran
> code is written.  For example, if it stores information in global
> variables then these
> may be left corrupted after ATC.  I'm not so worried by this, because I
> can check
> the code and do some rewriting if necessary.  I am more worried about
> the second
> kind of potential problem: will ATC trash memory etc because the code
> produced
> by the fortran compiler is not compatible with ATC?  I've no idea how
> ATC is
> implemented, so I've no idea if there could really be code compatibility
> problems
> or not.  Perhaps someone out there has some experience with this kind of
> thing...
> 
> I am using g77 (egcs version) for compiling the fortran and GNAT 3.12p
> for the
> Ada.

I'm not sure how GNAT supports Abort and ATC.  There are generally two
approaches, one which involves propagating a special exception, the
other involves doing the equivalent of a "longjmp."  Longjmp should
work independently of what kind of code g77 generates.  Using a special
exception may or may not work, depending on how exceptions are propagated
through non-Ada code.  This sounds like a question for the ACT folks...

Note that ATC is not some nasty Ada "invention."  It was inspired by
the ANSI C setjmp/longjmp and sigsetjmp/siglongjmp.  There are some
dangers in using ATC, but essentially every interactive program that
catches "control-C" on Unix and then re-prompts uses setjmp/longjmp 
or equivalent, so there is plenty of code out there that uses ATC-like
constructs.

> Thanks for your help,
> 
> Duncan Sands.
> 
> PS: Of course, I could wrap the Fortran code up in a protected object,
> and exploit the abort deferred property of protected objects to avoid
> having the abort come during execution of the Fortran code.  But since
> it is the Fortran part that is likely to need to be aborted (because it
> can take a long time to complete), this is not very satisfactory.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA