On 18/07/2026 19:56, NIkolai Marchenko wrote:
This is a bit of a non answer tbh. Like yes, should is fine and all but when the developers are weighing in about optimising something using a static object to avoid unnecessary construction, what is the correct procedure to approach?
We need a Qt project-level decision here: do we agree with formally extending the reentrancy contract, so that it's OK to call the same function, on the same data, from multiple threads, without synchronization, provided that any shared data is accessed exclusively along const paths¹?
In other words, that such functions are thread-safe, provided no one is also mutating the shared data at the same time?
I think we should officially extend the contract, because:1. in practice, it already applies in most places; we just need to adjust the documentation;
2. since it already works, people rely on it, whether it's documented or not;
3. C++ developers have the expectation that "const access on shared data is thread safe", which is for instance the guarantee of the Standard Library. With our reentrancy contract we're giving a weaker definition, which is surprising and error-prone.
The tradeoff is that the functions that are currently marked as reentrant and use lazy initialization, caching, or any similar thread-unsafe techniques, need to be documented to be *not* reentrant. Luckily there should be very few of such functions. I guess that documenting these few exceptions is a smaller loss than the gain of aligning ourselves to C++ established practices / people's expectations.
(I'm not really sure how to define such almost-reentrant functions, but that's a separate discussion.)
¹ "const path" isn't super formal, but it should give the idea. My 2 c, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence
smime.p7s
Description: S/MIME Cryptographic Signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
