From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!uakari.primate.wisc.edu!unmvax!sandia!sandia.uucp!kristina
From: kristina@sandia.uucp (Kristina Buchholtz (9226))
Newsgroups: comp.lang.ada
Subject: Ada and Isis
Keywords: Verdix 6.0 Ada, callbacks
Message-ID: <457@sandia.UUCP>
Date: 10 May 91 21:27:37 GMT
Sender: kristina@sandia.UUCP
Organization: Sandia Natl Labs, Div. 9224
List-Id: <comp.lang.ada>

Does anybody have any experience interfacing Ada with Isis?  I am using
Verdix 6.0 Ada on a Dec5000, and am experiencing problems when Isis
(written in C) does a callback to Ada.  Specifically, I get a 
Storage_Error when the callback is called, unless I do a pragma suppress
on Storage_Check (just an interim solution).  Then, one of my callbacks
(an Isis_Task callback) works ok, but another (an Isis_Entry callback)
dies on kernel access when it is called (it looks like its going below 
the user stack).

We have implemented signal handlers using callbacks (C to Ada), and those
work ok as long as we suppress elaboration checks on the callbacks.
Also, all of our Ada to C code works just fine.

I'm not sure if my problems are a consequence of the tasking mechanisms 
that Isis uses, or if it is just a problem with Verdix Ada callbacks.

On our Sun4's, I can get further; the Isis_Entry callback gets called ok
and can do things like C I/O, but if it tries Ada I/O or exception handling,
it dies.  The Verdix Ada manual does warn against having C mainline
programs, but I've even tried putting the Isis executables in Ada wrappers,
and get the same results.

Anybody have any idea where my problem lies?

Thanks for any Help

Kristina Buchholtz
uucp:      ...{ucbvax | gatech}!unmvax!sandia!kristina
InterNet:  unmvax.unm.edu!sandia!kristina