Just had a chance to look-up the code path that gets executed in Jean-Louis'
case:
* a Rexx interpreter instance (RII) is running,
* BSF.CLS gets called and needs to load and initialize the Java side, in
order to do so the
following steps occur
o create another Rexx interpreter instance (RII-2)
o create the Java infrastructure (instances of BSFManager, RexxEngine and
RexxAndJava)
o terminate the Rexx interpreter instance (RII-2)
Could it be, that the ooRexx Terminate()-API does not do a DetachThread(), such
that the activation
for RII-2 is not ended?
If so, is there anything one could do (like doing a DetachThread() in the
thread that invokes
Terminate()) ?
---rony
On 15.04.2012 14:48, Jean-Louis Faucher wrote:
ok, thanks.
Then I will see with Rony.
Jean-Louis
Le 15 avril 2012 14:09, Rick McGuire object.r...@gmail.com
mailto:object.r...@gmail.com a écrit :
On Sunday, April 15, 2012, Jean-Louis Faucher wrote:
What is the purpose of this code in getRootActivity ?
// Do we have a nested interpreter call occurring on the same
thread? We need to
// mark the old activity as suspended, and chain this to the new
activity.
if (oldActivity != OREF_NULL)
{
oldActivity-setSuspended(true);
// this pushes this down the stack.
activityObject-setNestedActivity(oldActivity);
}
I meet this case with ooRexxShell where BSF.cls is loaded.
One remark : I load BSF.cls to make it available from the command
line, but there is no
dependency on it.
Other remark : There is no reply in ooRexxShell, so everything runs
in one thread.
The executable section of BSF.cls calls CreateRexxInterpreter, which
calls
getRootActivity. This is done from the current thread running
ooRexxShell.
A new activity is created for the same thread, the old activity is
suspended (just a flag
set to true), but it continues to execute and everything works fine,
except one thing :
the calls to GCI registered routines no longer works (I use them to
change console
colors). This is because the variable pool is enabled for the old
activity, but not for
the new activity which is found by ActivityManager::findActivity from
the current thread id.
Call stack showing the problem :
rexx.dll!ActivityManager::findActivity
threadId = 57972
listIndex = 1 -- activity = 0x7f69bea8
rexx.dll!ActivityManager::findActivity
rexx.dll!ActivityManager::getActivity
rexx.dll!NativeContextBlock::NativeContextBlock
rexx.dll!RexxVariablePool
gci.dll!readRexx
gci.dll!GCI_readNewRexx
gci.dll!loadStem
gci.dll!GCI_execute
gci.dll!_GciDispatcher
rexx.dll!RexxNativeActivation::callRegisteredRoutine
rexx.dll!RegisteredRoutine::call
activity = 0x7eee5fa0 (old activity)
JLF : threadId = 57972
As explained above, the activity 0x7eee5fa0 has been suspended by
getRootActivity when
BSF.cls was loaded, but the ooRexx code continues to execute with
this activity. And the
variable pool is enabled for it.
For the moment, I don't know where to investigate... Is it a bad use
of
CreateRexxInterpreter ? or is it a problem with the interpreter
(running a suspended
activity) ?
Definitely a bad use of CtreateInterpreter. This creates a new active
instance on the thread,
which pushes down the instance that RexxVariablePool needs to interact
with.
Rick
Jean-Louis
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
