[Qt-interest] connection between qthreads blocks my gui

[K. Frank]

Hi Marek -

2010/12/14 franki <franki at franki.eu.org>:
> Wednesday 15 of December 2010 00:15:06 K. Frank napisał(a):
>> Hello Marek -
> ...
> Hello,
>
> For the moment being, my rs232Manager can do only one thing at the time, eg.
> it writes to device, waits for response, then it takes next job, so it is
> convenient to have QThread run this class with it's own eventDispatcher.

Yes, it absolutely makes good sense for your RS-232 stuff to reside
in its own thread.

> However who knows what may be next, app should grow over the time, or at least
> I hope so, and if it is a blessed way then i try to instantiate rs232Manager
> inside class derived from QThread.

I wouldn't say "blessed" -- just one of several legitimate design choices.

> But then... just quick thought:
> connect(guiClass,SIGNAL(doSomething()),rs232Thread->rs232Manager,SLOT(doWork()))
> Or should I do some function in rs232Thread to call rs232Manager to get the
> job done?

Well, whoever does the connect has to know about both guiClass / doSomething
and rs232Manager / doWork.  This is the sort of "cross-cutting concern"
that gives the object-oriented purists conniptions.  Do you have rs232Manager
make the connection, and pollute rs232Manager with knowing about guiClass?
Or do you pollute guiClass with knowing about rs232Manager?

Or do you create a third object whose sole responsibility is to know
about both guiClass and rs232Manager and make the connection?

One possibility, if you choose to derive an Rs232Thread class from
QThread, is to give Rs232Thread the responsibility for making
the connection (and therefore, for knowing about both guiClass
and rs232Manager).  Of course, this is impure, because it pollutes
the class that has responsibility for managing a thread of execution
(QThread, or in this case, the QThread-derived class) with knowledge
of guiClass and rs232Manager.  But, hey, object-oriented or no, you've
got to put that cross-cutting concern somewhere.

>
> On the other hand, I don't have anything against moving rs232Manager object to
> thread, and  I don't know what other functions would I implemet in
> rs232Thread (derived from QThread) providing that pure QThread object has
> it's own exec loop (since Qt 4.4 as I read), maybe for me it simply over the
> top to subclass the QThread.

Yes, QThread (and therefore a QThread-derived class) has its own event
loop.  But -- reminder -- if you derive from QThread, and override
QThread.run(),
you have to call exec() in your run method for the event loop to be active.

> Anyway, will try this tomorrow ;)
>
> many thanks
> Marek

Good luck.


K. Frank

>
>> 2010/12/14 franki <franki at franki.eu.org>:
>> > Tuesday 14 of December 2010 20:06:58 J-P Nurmi napisał(a):
>> >> On Tue, Dec 14, 2010 at 8:25 PM, franki <franki at franki.eu.org> wrote:
>> >> > ...
>> >> > I have some gui class (mainClass), inside that class I created two
>> >> > classes which subclass QThread,...
>> >> > ...
>> >> > Problem is, that this readWrite function blocks my entire gui when
>> >> > running, and as I read somewhere in case of QueuedConnection, the SLOT
>> >> > is executed inside receiver's thread, so why is this blocking my gui?
>> >> > ...
>> >>
>> >> Hi,
>> >>
>> >> Be careful with having slots in QThread subclasses. Check this
>> >> arcticle: http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/.
>> > ...
>> > So now I see some options
>> ...
>> > 1. Simplest (but I'm not sure if it meets all my needs) is to call
>> > moveToThread(this) inside class contructor, then all functions defined in
>> > class will move to separate thread and QueuedConnection signal-slot
>> > should work
>>
>> This should work.  I think it's a fine idiom for using queued
>> connections in a QThread-derived class.
>> ...
>> > best regards
>> > Marek
>>
>> Good luck.
>>
>> K. Frank
>> ...