[Development] Unnecessary ambiguity in Qt documentation about reentrancy and safety of const methods.

[Giuseppe D'Angelo]

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 | giuseppe.dangelo at kdab.com | 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4850 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260718/24e1a573/attachment-0001.bin>