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. Flatscher<[email protected]> 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. > Flatscher<[email protected]> 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
