[Interest] [QQuickView] deadlock on exit

[Sze Howe Koh]

On 9 January 2014 02:13, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On quarta-feira, 8 de janeiro de 2014 18:29:06, Tim Blechmann wrote:
>> > If the plugin is not using Qt, there's no threading issue. Qt requires its
>> > GUI to be run from one thread only, but it does not make any requirements
>> > on GUIs written without Qt.
>>
>> forgive my ignorance, maybe i'm missing something very stupid here: in
>> the case of a plugin, the host provides a native handle (HWND or
>> NSView*). i'm wrapping this native handle inside a QMacNativeWidget or
>> qwinwidget and place a QQuickView inside.
>> i'm not an expert with gui systems nor with qt, but from my
>> understanding this implies that the plugin's gui has to run in the same
>> thread as the host's gui. and therefore the QApplication must be created
>> in the gui thread and not in a separate thread.
>> and creating the QApplication in the gui thread, i cannot run exec()
>> without blocking the host's gui.
>
> Qt makes no such requirement. All it requires is that its GUI be run from one
> thread only, which we call the GUI thread. That thread must be the thread in
> which the first QObject is created. Since usually the first QObject created is
> QApplication or QCoreApplication in the main function, it's usually the main
> thread.
>
> However, the underlying system API may make other requirements. I have no clue
> about the thread-safety of Win32 or Cocoa.

AFAIK, the Cocoa framework mandates that all GUI-related operations
must be performed in the first thread of a process [1], i.e. the the
thread that calls main(). QApplication can be created in a separate
std::thread in Windows, but not on Mac OS X.


Regards,
Sze-Howe

[1] http://lists.qt-project.org/pipermail/development/2013-December/014702.html