On 18.11.2012 13:10, Rick McGuire wrote:
>
> On Sun, Nov 18, 2012 at 7:03 AM, Rony G. Flatscher
> <rony.flatsc...@wu-wien.ac.at
> <mailto:rony.flatsc...@wu-wien.ac.at>> wrote:
>
>
> On 18.11.2012 12:57, Rick McGuire wrote:
>> I don't have a suggested solution. I frankly don't think this is an RFE
>> that I think is a
>> particularly useful addition.
> O.K.
>
> How would you suggest to solve the following (generalized) problem:
>
> * a native library is used to interact with Rexx objects in a Rexx
> interpreter instance from
> an application that uses it for executing macros,
> * the Rexx interpreter instance got unexpectedly terminated due to an
> error in some Rxx
> code, such that any further calls using it may lead to a crash in the
> Rexx interpreter;
>
> It probably boils down to the question: how could/should the native code
> learn whether a
> cached Rexx interpreter instance is still available for use (to avoid any
> crashes)?
>
>
> If your native library is not the one creating the instance, then you
> probably should not be
> caching the instance in the first place, but rather using whatever is given
> to you on context
> callbacks. Doing it any other way is making some unwarranted assumptions
> that there is only a
> single instance active in the process that might be using that library.
There are two different kinds of cachings done:
* One for the Rexx interpreter instance that was created by the Java side; if
that Rexx
interpreter instance gets terminated by the Java side, then the Java side
will inhibit any
callbacks to the Rexx interpreter instance,
* Cachings for ooRexx objects for which Java proxies get created to allow
Java programs to
interact with the ooRexx objects by sending them messages and fetching
their results; if a Rexx
interpreter instance got terminated, the message is not forwarded to Rexx
anymore, but an
appropriate Java exception gets created.
o In the case that Java proxies for Rexx objects get garbage collected,
there is a finalize()
method implemented which allows the native code to release the
reference to the proxied Rexx
object (which gets established to hinder the ooRexx garbage collector
to collect proxied
ooRexx objects; these references are reference counted).
As long as everything works/executes according to the specs, everything is fine.
In the AOO case there is one situation that arises from time to time where Rexx
crashes. Analyzing
the reason gives: when a Rexx program loads the Java support (such that Java is
not in control of
the Rexx interpreter instance) and Rexx then loads the UNO/AOO support, there
are quite a few Java
proxies to Rexx objects created. When the Rexx program gets stopped by the Rexx
interpreter due to a
Rexx condition (e.g. a syntax condition raised because of a Java error), then
from time to time
(not every time) there is a Rexx crash. This looks as if the Rexx interpreter
was not stable, when
in reality the native code forwards messages from Java to Rexx objects, but the
Rexx interpreter
instance is not valid anymore.
So far, I have not been able to come up with a strategy that allows the native
code to not carry out
the message forwarding from Java to Rexx, e.g. in the case of finalize(), but
also sometimes event
handler invocations, where the event method is implemented as a Rexx method and
the like.
The only solution that I see is some means for the native code to learn whether
it is safe to use a
Rexx interpreter instance in that particular use case. Hence that RFE and the
attempts to implement
"something" that would supply that information in a "cheap" way (would have to
be checked every time
before forwarding a message from Java to a Rexx object).
For this nasty problem, it would be sufficient, if there was some flag or some
function call or some
Rexx exit that can be used to learn whether it is safe to interact with Rexx
from the native code.
---
It would be great also, if you had any idea/suggestion how to solve this
problem differently
(without the need of such a RFE)
---rony
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
