[Oorexx-devel] Two questions ad exit-handlers on 3.2 and 4.0

2009-04-02 Thread Rony G. Flatscher
Hi there,

in news:comp.lang.rexx Erik Duijs posted a problem that relates to an
RXSIO exit.

Use-case:

Using BSF4Rexx a Java program dispatches a Rexx script, which in
turn uses Java to dispatch another Rexx program in the same thread.
Each dispatch of a Rexx program from the Java side has currently the
following logic:

* RexxRegisterExitExe(..) is used to register an RXSIO exit
  handler for the UserArea argument a local character array is
  used which gets data stuffed into it in a FIFO-fashion,
* RexxStart(...) gets a RXSYSEXIT list supplied that denotes
  that RXSIO exit handler,
* RexxDeregisterExit() is used to deregister the RXSIO exit handler.


Running under ooRexx 3.2 the invocation of another Rexx script via Java
from the first Rexx script fails upon returning to the first Rexx script
and writing something to stdout.

However, running the same program under the latest build of ooRexx 4.0
will correctly run the program. It seems that ooRexx 4.0 is able to
distinguish the RexxDerigsterExit() from each other (whereas in the
ooRexx 3.2 case it seems that deregistering affects both interpreter
instances and causes the exit failure by ooRexx).

The question would be: can one rely on ooRexx 4.0 to deregister the
matching (nested) exit handler?

A second question: removing the RexxDerigsterExit(...) from the code
allows the programs to run correctly under both, 3.2 and 4.0. Are there
any side-effects one should consider if not deregistering the
(continuously) registered exit handlers?

---rony





--
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel


Re: [Oorexx-devel] Two questions ad exit-handlers on 3.2 and 4.0

2009-04-02 Thread Rony G. Flatscher


Rick McGuire wrote:
 2009/4/2 Rony G. Flatscher rony.flatsc...@wu-wien.ac.at:
   
 Hi there,

 in news:comp.lang.rexx Erik Duijs posted a problem that relates to an
 RXSIO exit.

 Use-case:

 Using BSF4Rexx a Java program dispatches a Rexx script, which in turn uses
 Java to dispatch another Rexx program in the same thread. Each dispatch of a
 Rexx program from the Java side has currently the following logic:

 RexxRegisterExitExe(..) is used to register an RXSIO exit handler for the
 UserArea argument a local character array is used which gets data stuffed
 into it in a FIFO-fashion,
 RexxStart(...) gets a RXSYSEXIT list supplied that denotes that RXSIO exit
 handler,
 RexxDeregisterExit() is used to deregister the RXSIO exit handler.

 Running under ooRexx 3.2 the invocation of another Rexx script via Java from
 the first Rexx script fails upon returning to the first Rexx script and
 writing something to stdout.

 However, running the same program under the latest build of ooRexx 4.0 will
 correctly run the program. It seems that ooRexx 4.0 is able to distinguish
 the RexxDerigsterExit() from each other (whereas in the ooRexx 3.2 case it
 seems that deregistering affects both interpreter instances and causes the
 exit failure by ooRexx).
 
 The different in 4.0 is how Rexx is using the registered exit
 information.  In 3.2.0, the exit handler was queried on each call to
 the handler, so deregistering the handler will cause an error, as you
 observed.  In 4.0, the information about the handlers is resolved once
 at the RexxStart initial startup, and that entry point information is
 used for all calls.  Deregistering the handler has no effect.

   
 The question would be: can one rely on ooRexx 4.0 to deregister the matching
 (nested) exit handler?
 

 No, the interpreter never deregisters a handler.

   
 A second question: removing the RexxDerigsterExit(...) from the code allows
 the programs to run correctly under both, 3.2 and 4.0. Are there any
 side-effects one should consider if not deregistering the (continuously)
 registered exit handlers?
 

 It depends on the type of hander being registered.  If you are using
 RexxRegisterExitExe() (which you seem to be), then all of those exits
 will be deregistered when the process that registeres them terminates.
  If you're using the DLL form, then they are persistent.
   
Thank you very much, indeed!

---rony

--
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel