tuukka.turunen at qt.io
Thu Sep 19 13:47:32 CEST 2019
A lot of the Qt functionality works perfectly well on INTEGRITY. Even the advanced graphics such as Qt Quick, Qt 3D and Qt 3D Studio. I do not see it reasonable to claim that it is "so far behind all the other supported platforms, as well as its own claim of conformance, that the question must be asked why it's still supported". Like any RTOS platform, there are known restrictions in the functionality supported on INTEGRITY: https://doc.qt.io/qt-5/integrity.html. If there are additional restrictions, those should be added to the platform notes. There also may be work arounds needed for some items, as suggested. In case of issues with the OS or the compiler, it is also possible to report a bug to Green Hills.
On 19/09/2019, 12.21, "Development on behalf of Mutz, Marc via Development" <development-bounces at qt-project.org on behalf of development at qt-project.org> wrote:
On 2019-09-19 10:56, Lars Knoll wrote:
>> 4. drop Integrity support (or update to a newer version) ASAP (for
>> Qt 5.15 if not 5.14).
> This is a bit black and white. You’re proposing to drop all of
> INTEGRITY because you’re not willing to work around things on that
> platform for one patch that is in principle a pure cleanup patch doing
> internal refactoring. It wouldn’t be too difficult (though maybe not
> very nice looking though) to keep the old code for INTEGRITY only.
> It’s been tested and we know it works.
> We’ve been applying workarounds for missing support for some C++11
> features in other toolchains/compilers as well. We kept the Atomic
> implementations for MSVC around for exactly the same reasons.
That may work for the series of patches that implements QWaitCondition
using std::condition_variable, which, indeed, is just a cleanup patch.
But it helps nothing with all the places where we use QWaitCondition in
Qt implementation and would like to replace it with
std::condition_variable + std::mutex, because, as I explained in an
earlier mail, QWaitCondition is a condition_variabe_any and thus has
inherently and unavoidably more overhead than condition_variable +
mutex. There is no justification to add #ifdefs for all the places that
QWaitCondition is used unconditionally now, so either we don't get the
order-of-magnitude improvement on our main platform, Windows, or we need
to introduce a private QtPrivate::condition_variable as an inline
wrapper around condition_variable + mutex or, for Integrity,
QWaitCondition + QMutex, which we need to replace once more with
std::condition_variable + mutex if Integrity is fixed. Is it worth it,
for a buggy platform that's in the process of being fixed? I'm not sure
it would be...
In addition, as Peppe noticed, this is not the first time Integrity has
shown up as a problematic platform, and it now is so far behind all the
other supported platforms, as well as its own claim of conformance, that
the question must be asked why it's still supported.
Development mailing list
Development at qt-project.org
More information about the Development