How is QClipboard::mimeData's returned pointer "invalidated"?
-
The Qt6 documentation for QClipboard::mimeData states "The pointer returned might become invalidated when the contents of the clipboard changes; either by calling one of the setter functions or externally by the system clipboard changing." I'm having trouble understanding how this method can be safely used if this is the case. Does "invalidated" actually mean it may be freed at any time from a system thread that you have no knowledge of or control over? Or only that the pointed-to object may be changed in place? And if the latter, is it guaranteed to be thread-safe to read concurrently? Even if all methods are thread safe, it seems like the class interface is inherently vulnerable to race conditions e.g. if the clipboard is changed between calling formats() and data(), or hasText() and text().
Experimentally, it seems that the formats and data of the returned object do change asynchronously, even in a single threaded program without starting the Qt event loop. That seems to imply there is a background thread updating the object in place. Or is it actually polling for changes in the read APIs?
Note: I'm experimenting in Python/PySide, not C++, so I'm not sure if that fundamentally changes the threading guarantees here, but I'm interested in the underlying C++ behavior.
-
The Qt6 documentation for QClipboard::mimeData states "The pointer returned might become invalidated when the contents of the clipboard changes; either by calling one of the setter functions or externally by the system clipboard changing." I'm having trouble understanding how this method can be safely used if this is the case. Does "invalidated" actually mean it may be freed at any time from a system thread that you have no knowledge of or control over? Or only that the pointed-to object may be changed in place? And if the latter, is it guaranteed to be thread-safe to read concurrently? Even if all methods are thread safe, it seems like the class interface is inherently vulnerable to race conditions e.g. if the clipboard is changed between calling formats() and data(), or hasText() and text().
Experimentally, it seems that the formats and data of the returned object do change asynchronously, even in a single threaded program without starting the Qt event loop. That seems to imply there is a background thread updating the object in place. Or is it actually polling for changes in the read APIs?
Note: I'm experimenting in Python/PySide, not C++, so I'm not sure if that fundamentally changes the threading guarantees here, but I'm interested in the underlying C++ behavior.
@rmccampbell
Good question, worrying, and I don't know the answer. The only thread I could come across confirms it is not thread-safe but I'm not sure it answers your question or the implications. However it is worth reading through: Is it safe to use QClipboard in a background thread
