[Oorexx-devel] Another idea ... (Re: RFH for implementing RFE # 356

[Rony G. F. <Ron...@wu...>]

Would it be possible to have a Rexx exit defined for terminating a Rexx interpreter instance?

If so, then this would allow for solving the sketched problem/use case.

---rony



On 18.11.2012 13:29, Rony G. Flatscher wrote:
>
> On 18.11.2012 13:10, Rick McGuire wrote:
>>
>> On Sun, Nov 18, 2012 at 7:03 AM, Rony G. Flatscher <Ron...@wu...
>> <mailto:Ron...@wu...>> 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