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)


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!
Oorexx-devel mailing list

Reply via email to