No, it would not. This assumes that the memory for the instance structure
has not been reused by the interpreter after the termination. Since it is
just an object instance, this would not be the case. Forcing these objects
to remain referenced would create an undesirable memory leak.
Rick
On Sun, Nov 18, 2012 at 6:47 AM, Rony G. Flatscher <
rony.flatsc...@wu-wien.ac.at> wrote:
> In order to remove a crash in ooRexx when using ooRexx from OpenOffice
> (AOO) via BSF4ooRexx, I am contemplating to implement RFE
> <http://sourceforge.net/p/oorexx/feature-requests/356/><http://sourceforge.net/p/oorexx/feature-requests/356/>
> .
>
> However, short of having the needed overview about how the pieces fit
> together, a RFH (request for hints/help) of which parts of the interpreter
> need to be taken care of.
>
> My initial (unsubstantiated) thoughts go along the lines:
>
> - it is sufficient to become able to learn whether a Rexx interpreter
> instance is in the process or has terminated, i.e. whether a
> context->Terminate() has been issued for that Rexx interpreter instance,
>
> - This assumes that if the Rexx interpreter needs to interrupt and
> end a Rexx program, e.g. because of a syntax condition that does not get
> trapped, the Rexx interpreter will use Terminate() on that Rexx
> interpreter
> instance. If the Rexx interpreter ends a Rexx program in error
> differently,
> then it would be important to learn somehow that no Rexx interpreter
> instances are usable anymore.
>
> - The idea would be to add boolean field named isTerminated to the
> context structure, which initially is set to false. context->Terminate()
> then would change that field to true.
>
> - This way, native code will become able to learn whether the Rexx
> interpreter instance is still usable by merely inspecting that field in
> the
> context structure.
>
> - In the AOO use case the native code in BSF4ooRexx would then
> become able to learn whether a callback into the Rexx interpreter
> instance
> would be safe or not, and react accordingly (e.g. raising an appropriate
> Java exception indicating the correct cause), such that no crash of
> ooRexx
> needs to occur anymore.
>
> Would that yield a feasible, sensible solution?
>
> ---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
>
>
------------------------------------------------------------------------------
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
