Being myself not a software developer per se, I had to look up what this was
about.
[https://en.wikipedia.org/wiki/Thread_safety](https://en.wikipedia.org/wiki/Thread_safety?wprov=sfti1)
Kind regards,
David
Sent from [Proton Mail](https://proton.me/mail/home) for iOS
On Thu, Jun 26, 2025 at 08:06, Greg Hellings
<[greg.helli...@gmail.com](mailto:On Thu, Jun 26, 2025 at 08:06, Greg Hellings
<<a href=)> wrote:
> I seem to recall some discussion on thread safety in the engine, specifically
> in the context of, "There is none". Is that true?
>
> I was writing some multi-threaded code that was behaving oddly around the
> VerseKey class and I couldn't at first figure out why my tests were failing
> intermittently. All I was doing was instantiating a VerseKey, setting its
> text, and then reading the parsed values in each test function. I eventually
> tracked it down to a race condition in the
> VersificationManager::getSystemVersificationManager() factory method.
>
> The briefest glance at the code shows that it has no thread safety in
> constructing the manager and applying it to the global instance. That alone
> was enough to cause the intermittent failures. My testing showed it clearly
> was a threading race condition, as it would seemingly appear at random
> throughout the code - sometimes manifesting as just a null pointer reference,
> sometimes as an allocation issue, and sometimes even as a UTF-8 encoding
> issue for the text I was passing in!
>
> So the question: is this intentional? Do we have a solution for thread safety
> in the engine, or do we simply not offer any guarantee of thread safety? I
> know Troy has mentioned that SWMgr is not thread safe, and he will often have
> 3 instances of it for doing different tasks. However, even if that approach
> was taken, they three would share the state of this one static global. In an
> application, the solution here would be to just pre-emptively call
> getSystemVersificationMgr before any other code might access the VerseKey
> class. However, in my case, the code was all running in a test suite that did
> not offer a solution to ordering the code and ensuring some setup code was
> executed first.
>
> For now my solution is just to disable parallel test running, but I wanted to
> see if this acceptable thread safety, or if this is a place where thread
> safety was unintentionally being violated.
>
> --Greg
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
