Except there's possible race-condition if quit() is called before loop started, isn't it? At least, qthread::exec do some checks under mutex
Иван Комиссаров > 21 нояб. 2018 г., в 16:10, Olivier Goffart <[email protected]> написал(а): > >> On 21.11.18 15:47, Volker Hilsheimer wrote: >>> On 20 Nov 2018, at 14:30, Иван Комиссаров <[email protected]> wrote: >>> Hello, I've noticed that it would be nice to run QThread::exec() from a >>> functor passed to QThread::create(). However, exec is marked as protected, >>> thus I can't call QThread::currentThread()->exec(). >>> Maybe it is worth to make exec() public method? Or make it static, like in >>> QApp (is it BC?)? >>> This would be a nice addition to the create() method so worker objects can >>> be created in a functor on stack instead of moving them to thread. >>> >>> Иван Комиссаров >> The reason why QThread::exec is protected so that people don’t get tempted >> to call it directly on a QThread object and expecting that the event loop is >> somehow executed in a separate thread. It is useful to generate a >> compile-time error when this is attempted: >> QThread *heyNewThread = new QThread; >> heyNewThread->exec(); >> I would rather not remove that limitation (and it would break BC on >> compilers that include the access level in the generated symbol). Making >> exec() public would indicate that the above is ok, while it actually breaks >> the semantics. > > No need to access QThread::exec(). > One can just call > > QEventLoop().exec(); > > And that has the same effect. > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
