Re: [Oorexx-devel] Ad possible use of recursive locks (Re: No, only the hang bug left and that can be solved with Dom Wise's patch (Re: Maybe two different bugs? A question ad fixing the hang

Thu, 30 Oct 2025 09:07:42 -0700 

Dear Dom,

On 30.10.2025 13:29, [email protected] wrote:


Thank you very much for committing the patch.


My pleasure, and my kudos to you!


I feel much better knowing that the potential time bomb that I added has now 
been defused 😊


:)


The way I see it is that you came up with a reliable first solution that will work flawlessly with 
the current software infrastructure in use.



However, I see it also as very responsible and diligent of you to look into possible future software 
infrastructures and make sure that no ill side-effects can occur.



Also, IMHO it is great for the project to see your thorough and helpful work which enhances and 
fortifies ooRexx!


Best regards

---rony




*From:*Rony G. Flatscher <[email protected]>
*Sent:* 27 October 2025 14:40
*To:* [email protected]

*Subject:* Re: [Oorexx-devel] Ad possible use of recursive locks (Re: No, only the hang bug left 
and that can be solved with Dom Wise's patch (Re: Maybe two different bugs? A question ad fixing 
the hang


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



























					Reply via email to