Greetings Dom,
We are all learning I appreciate your willingness to contribute to ooRexx! It has been many years since I had something of value to contribute to ooRexx C code. That has since been ported to C++,
and I dare say now I would not even recognize the code. ;-)
Multiple releaseAcc
+299,7 @@
{
terminationSem.post();
}
+ActivityManager::releaseAccess(); // hack kudos to Dom Wise (20250817
e-mail on developer list), remove kernel lock again
return true;
}
Of course, once a fix can be found, this patch should be replaced.
First I will create an entry in t
Hi Michael,
Thank for your kind words but given the follow up from Rony I think the
jury is (and needs to be) still very much out on this one, for now at least
:)
Kind Regards,
Dom
-Original Message-
From: Michael Lueck
Sent: 17 August 2025 21:37
To: Open Object Rexx Developer Mailing
runk to
see, how it does on all Jenkin hosted operating systems.
Here the patch I have been using and testing (yes it fixes the hang, *very*
appreciated!!):
Index: interpreter/runtime/InterpreterInstance.cpp
===
--- interpreter/run
Greetings Don,
dominicjw...@gmail.com wrote:
but in the end I gave up and as a hack added an extra call to
ActivityManager::releaseAccess() at the end of this function. This seems to
have done the trick and the program runs ok with this in place.
(Chuckle)
About par with me making thr
copy) @@ -299,6 +299,7
@@ {
terminationSem.post(); } + ActivityManager::releaseAccess(); // hack kudos
to Dom Wise (20250817
e-mail on developer list), remove kernel lock again return true; }
Of course, once a fix can be found, this patch should be replaced.
First I will create an entry in
Hi,
I am one such masochist that Rony was referring to 😊
It seems that in InterpreterInstance::terminate() there can be situations where
the kernel lock ends up being taken twice. It is only ever released once and
this means that when it has been locked twice the thread leaves the function
own
Hi Michael,
On 17.08.2025 03:47, Michael Lueck wrote:
W O W ! ! ! Bravo!!! A most impressive success milestone!
but not solved yet. It looks as it is somehow linked to terminating interpreter instances right
before the callback from Java into ooRexx. The change I made was a debug output state
