This is exactly the last scenario I described to you yesterday and you adamantly declared that RexxCreateInterpreter was not getting called. There is an association between a thread and the "top-most" thread context that is created on that thread. Once you call RexxCreateInterpreter on a given thread, you've created a new thread context and all legacy callbacks will map back to the the instance that is at the top of the call stack.
I see you have two choices for calls that involve this sort of nesting: 1) Spin off a thread that creates an interpreter instance and holds it active, then use AttachThread()/DetatchThread() on that instance for all of your callbacks. 2) Since the first usage is initiated by Rexx code, just use the interpreter instance from the initial call context as your active instance. The subsystem is doing exactly what it is supposed to be doing, but real care needs to be taken to appropriate use the created call contexts. Rick On Tue, May 26, 2009 at 8:53 AM, Rony G. Flatscher <rony.flatsc...@wu-wien.ac.at> wrote: > > Rick McGuire wrote: >> I just thought of one more thing that could cause the error you're >> seeing. If you do an AttachThread() at some point and neglect to do a >> corresponding DetachThread() before returning to your caller, you'll >> end up with a corrupted activaation stack that will result in problems >> with legacy callback APIs like RexxVariablePool or RexxStemSort. >> What;s showing up in this traceback very much appears to match what >> might happen in that sort of situation. >> > Finally could trace this down and come by that problem. However, it has > nothing to do with AttachThread() and DetachThread()! > > The following happens: rexx.exe runs a rexx script which loads BSF4Rexx > and then Java. This will cause on the Java side the creation of another > RexxInterpreterInstance in the same thread that does not get used at > all, as upon return the current executing rexx scripts continues to run. > Then, from this script calls to the external function BSF() occur, which > means that that function has a callContext availble for further > processing (hence no need in this case to execute an AttachThread() and > DetachThread()). > > Not sure, whether this is a bug in the interpreter runtime. It seems > that after creating a new Rexx interpreter instance that unused instance > later interferes with the original Rexx interpreter instance? > > ---rony > > P.S.: This use case is not yet debugged in full, as I run into problems > in the unloader, which may have to do with this. Will only be able to > trace that further later in the afternoon, or if all goes foul only > tomorrow. (And then going after the particular multithreading problem I > have been chasing down, in the case of multithreaded executed Rexx > scripts that get halted.) > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
