On 21/07/2026 15:43, Volker Hilsheimer wrote:
Ideally, we can extend the documentation language that gets generated for the `\reentrant` tag (and/or the general overview documentation on reentrancy) to state that calling read-only members from multiple threads on the same instance of this class is defined behavior, unless documented otherwise. We can’t do that unless we are sure that this is true for all `\reentrant` classes, and have explicitly documented the exception for those cases where it is not.But perhaps a new `\reentrant_extended` qdoc macro that we introduce gradually as we identify compliant classes might be ok; we’d probably want to add a new `\reentrant_with_exception` macro to tag non-compliant classes. Either way, unless someone does it, it won’t get done :) If there is a group of people that would like to work on it, then that’s the group of people that will push the change they’d like to see.
To be honest, one of the point raised in the thread is that for 99.99% of the existing code in Qt, this extended reentrant contract already applies, and people are relying on it. It feels backward to have to audit everything and progressively change the docs, rather than simply changing the definition of "reentrant" (as generated by the existing \reentrant) to the extended one, and mark the 2-3 places we know about where const functions are not reentrant.
It still leaves two problems on the table,a) how to describe thread-safe / reentrant in a better way that it's not tied to an individual function (you can call *different* thread-safe/reentrant functions on the same data);
b) how do we call non-reentrant functions. This is currently a mix of at least 3 levels:
1. the _current_ reentrant definition: OK to call from multiple threads on different data, but same data requires synchronization, even if access happens through const paths. "Thread-exclusive"?
2. "Thread-affine" (?) i.e. most QObject subclasses. One can create them from an arbitrary thread, and even move the affinity, but then one must touch those objects only from a specific thread.
3. "Thread-pinned" (?), i.e. usable only from a _specific_ thread. QWidget, QPixmap (GUI thread only); a bunch of QSG* classes (Qt Quick render thread only); and so on.
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
