Filerules : non-reentry issue in Config::getRuleFromFilepath public function

[polystyren]

https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/05466120f3f9c23b23778f3ccbafc4dde93abe4b/src/OpenColorIO/FileRules.cpp#L638C25-L638C32

Hello,

I've recently migrated my code from the deprecated Config::parseColorSpaceFromString to the recommended Config::getColorSpaceFromFilepath, and encountered a thread-safety issue.

In FileRules::Impl::getRuleFromFilepath(), the method matches() is called in what appears to be a read-only context, implying it should be thread-safe.

However, when a rule is of type FILE_RULE_PARSE_FILEPATH, the matches() method may modify the internal m_colorspace member as a side effect. This introduces shared mutable state, which breaks thread safety when getColorSpaceFromFilepath() is used concurrently on a shared ConstConfigRcPtr.

This behavior leads to data races or inconsistent results in my multi-threaded application.

[remia]

I'm wondering if instead of updating this m_colorspace mutable member inside matches() we could not just return additionally the colour space name, or update an out parameter accordingly. It don't seem we need to store the dynamically matched name any longer and this could avoid serialising with a mutex.

PR are always welcome @polystyren if you have the bandwith!

Thanks for the report.