All of the symptoms you describe would suggest you are not terminating
your interpreter instances correctly...but that's what I suggested
earlier...
Rick
On Sun, Jun 14, 2009 at 6:40 AM, Rony G.
Flatscherrony.flatsc...@wu-wien.ac.at wrote:
Rick McGuire wrote:
I've already given you my theories as to why the unloaders might not
be running, but you've already discounted the theory.
No, but unfortunately I could not take advantage of it such that it has
become possible for me to pin the problem down and in turn becoming able to
fix the behavior!
:(
If I have something to debug, then I can probably give you an answer in
fairly short order.
That would be really just great! Currently, I am in the midst of a fairly
major change (which at the same time affects the dll but also the supporting
Java classes), such that it will take me until this evening to arrive at a
stable milestone again. If I may, I would then create a debug package with
a nutshell example.
As for the uninits not running, if you were anchoring the objects in
.environment, then those objects will never be eligible for garbage
collection, since that directly never gets garbage collected and CAN'T
be garbage collected, since you need that directory available to be
able to run the uninits in the first place.
Yes, I understand that.
In this case none of the Rexx objects are saved in .environment (nor in
.local). The uninits run if the Rexx scripts are invoked via rexx.exe, they
do not run for the same objects if the Rexx script is invoked via Java
causing the following native code to be executed:
RexxRoutineObject rro=rtc-NewRoutine(c_fileName, c_programData, len);
if (rro==NULL) // something went wrong, condition will be set
{
break;
}
result_obj=rtc-CallRoutine(rro, ra); // call the program
(As the uninits do not run, it is somehow as if the program is regarded to
not have ended.)
---rony
On Sun, Jun 14, 2009 at 5:58 AM, Rony G.
Flatscherrony.flatsc...@wu-wien.ac.at wrote:
Currently, the BSF4Rexx.dll works as intended, if Rexx scripts are
started via rexx.exe, and the dll is loaded via rexx.exe. The loader
function runs when BSF4Rexx gets loaded, the uninits and the unloader
function run, upon termination of the Rexx script.
In use case # 2, Java loads BSF4Rexx.dll, creates an interpreter
instance (which causes the loader function for BSF4Rexx to run) and
executes Rexx scripts via that instance. When the interpreter instance
terminates, no uninits nor the unloader function runs.
So far, I have not been able to figure out why use case # 2 would
exhibit this deviating behaviour. Just wanted to add the info that the
uninits are not run either upon termination of that Rexx instance.
Again, any ideas of what might cause this or what I may do to corner
that problem are highly appreciated!
---rony
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
