[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Multi-threaded programming involving the GUI thread?
From:       Robert Knight <robertknight () gmail ! com>
Date:       2010-01-15 12:17:01
Message-ID: 13ed09c01001150417q53b9f5d5pc3f03e3c479406e3 () mail ! gmail ! com
[Download RAW message or body]

> And how exactly is that supposed to happen? If a function used by the thread
> to do a part of the work waits for the thread to finish, you seem to have a
> serious design problem.

That is not what I meant.  Perhaps I missed something obvious.  Take
the case of an image viewer which loads the image in a worker thread
and for some quirky reason, the worker wants something done in the
main thread.

1.  Application starts
2.  User opens document
3.  Image loader begins loading file in worker thread
4.  User clicks main window's close button
5.  Image loader issues blocking call to main thread
6.  Application waits for image loader to finish
7.  Application exits

Supposing the image loader makes some call back to the main thread,
using a blocking connection and is waiting for the main thread to
respond when step 6 is reached, you'll get a deadlock if the 'waits
for image loader to finish' part is blocking (eg. using
QThread::wait(), QFutureWatcher::waitForFinished()).  Looking at the
gwenview 1.3 code, it explicitly handles this case in
ThreadGate::color() using emitCancellableSignal().

Regards,
Robert.

2010/1/11 Lubos Lunak <l.lunak@suse.cz>:
> On Friday 08 of January 2010, Robert Knight wrote:
>> > In KDE3 Gwenview I had few places where a worker thread needed a little
>> > thing to be done in the UI thread, in the middle of the work of course. I
>> > created for it what I believe Qt4 has as Qt::BlockingQueuedConnection (I
>> > haven't tried it).
>>
>> This approach can be used but you need to be careful about blocking
>> signal emissions from a worker thread to the main thread because
>> you can easily end up with a deadlock when the application shuts down
>> if the main thread waits
>> for the worker job/thread to finish whilst the worker is waiting for a
>> response to a signal from
>> the main thread.
>
>  And how exactly is that supposed to happen? If a function used by the thread
> to do a part of the work waits for the thread to finish, you seem to have a
> serious design problem.
>
>  My KDE3 code actually had support for cancelling signals as part of the whole
> threads support, but I can't think of a single good reason why there should
> be a deadlock. Emitting signal at the end about the task being finished
> doesn't need to be blocking -> no problem. Helper calls to the UI thread in
> the middle are not supposed to call back "up the backtrace" or do event
> processing or similar things that could lead to a circle -> no problem.
>
>> As far as I know, Qt::BlockingQueuedConnection does not provide a way
>> to cancel the call once it is
>> in-flight.
>>
>> There are several options I can think of to avoid the problem.
>>
>
>  4. Do not create the problem in the first place.
>
>> You also need to bear in mind that any points in the worker where it
>> is waiting for the main thread to do some work can
>> add quite a bit to the total time for the operation because of the
>> round-trip delay when sending messages between threads.
>
>  Obviously.
>
> --
>  Lubos Lunak
>  openSUSE Boosters team, KDE developer
>  l.lunak@suse.cz , l.lunak@kde.org
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]