[Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released
thiago.macieira at intel.com
Thu Sep 8 23:23:00 CEST 2022
On Thursday, 8 September 2022 14:06:24 PDT Albert Astals Cid wrote:
> Should we restore those symbols or just accept that Qt 6 broke BC a year ago
> and no one realized so why bring the symbols back?
The commit message says
Remove the dead code for blocking methods from QtConcurrent
After 79fd1cb2c631b6084bf10874205d27f5b53c907a the methods for running
QtConcurrent algorithms in the blocking mode aren't used anymore. Since
ThreadEngineBase and ThreadEngineStarter classes aren't meant to be used
externally, it should be fine to remove startBlocking() methods now.
ThreadEngineBase is used only by ThreadEngine, plus its static
ThreadEngineBase::threadPool is used by IterateKernel::forThreadFunction().
But ThreadEngine is a template class deriving from ThreadEngineBase, and
IterateKernel is a template class deriving from ThreadEngine and that is in
turn a base class for a lot of other classes.
Therefore, ThreadEngineBase is used by user code, only indirectly.
So the question is whether the removed function was ever callable in
QtConcurrent from 6.0 to 6.3. The commit this commit refers to landed in 6.0.
So if the commit message is correct, then there's no problem in Qt 6, because
if something still called this function, it would have broken in this commit.
According to the Git log, 1bf75f2a661c05c7f1126187310d7df3f9704af5 is the only
commit since Git tag v6.0.0 that touches a line that mentions "startBlocking".
Therefore, there is no BC problem in Qt 6.
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
More information about the Development