Hi Dom, On 27.10.2025 15:36, dominic wise wrote:
Ok you forced it out of me ;)
:)
I have tried out C++ recursive mutexes and they definitely break with the current code as any normal termination of a Rexx interpreter instance hangs due to the negative lock count. I don't recall the details 100% but I'm fairly confident this actually prevents the build from completing as there are some places where a Rexx interpreter is spun up during the build and these hang as well.
And with your fix applied (it got committed as you may have seen)? Kind regards ---rony
On Mon, 27 Oct 2025, 11:03 Rony G. Flatscher, <[email protected]> wrote: Dear Dom: On 26.10.2025 17:53, [email protected] wrote: ... cut ..The patch as it stands carries out an extra lock release in InterpreterInstance::terminate whether it needs to or not just to deal with the case where an extra one is actually needed because a new activity was created. For cases where it is not needed this extra unlock theoretically leads to the lock count becoming negative. The locks we currently use are forgiving of and ignore this but it is still wrong, and were we ever to switch to using different locks (e.g. C++ recursive_mutexes – which I **might** have tested locally) or should future operating system releases be less forgiving this imbalance could causes deadlocks or other errors when interpreter instances shutdown “normally” (i.e. without the extra activity creation)Hmm, what would you think would have happened if you had tested e.g. C++ recursive_mutexes [1], would have everything continued to work in ooRexx, i.e. would the test suite have passed? ;) Best regards ---rony [1] <https://prodevelopertutorial.com/c-11-feature-c-multithreading-tutorial-recursive-mutex-in-c-threading/> <https://prodevelopertutorial.com/c-11-feature-c-multithreading-tutorial-recursive-mutex-in-c-threading/>
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
