[Qt-interest] connection between qthreads blocks my gui

[franki]

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:
> > Hi all,
> >
> > I have some gui class (mainClass), inside that class I created two
> > classes which subclass QThread, one of which is sending/receiving data
> > from rs232, lets say rs232Thread, second one is sending signal to start
> > reading from rs232,lets say cronThread. Connection is defined inside
> > mainClass like this:
> > connect(cronThread,SIGNAL(startChecking()),rs232Thread,SLOT(readWrite()),
> >Qt::QueuedConnection)
> >
> > 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?
> >
> > The only way I can do it without blocking gui is to place function
> > readWrite inside run() of this rs232Thread and connect signal from
> > cronThread to some function (defined in rs232Thread) which starts run().
> >
> > What am I doing wrong? Is this a problem that connection between this two
> > threads is defined inside mainClass (which is gui thread) ? Or there is
> > something else?
>
> Hi,
>
> Be careful with having slots in QThread subclasses. Check this
> arcticle: http://labs.qt.nokia.com/2010/06/17/youre-doing-it-wrong/.

I have read this

Well... I was using mandelbrot example and qt docs, and it looks like all I 
was doing was 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
2. Rewite code to make my classes derived from QObject, as I need them to send 
signals after work done, and slots are needed of course, and after creating 
the object move class to separate thread
3. Someone has mentioned using RegisterdThreads and then all slots will be 
executed in just created thread
4. for these people who were claiming that they never have to use moveToThread 
I suppose they were doing some sort of job queue on their own, right? So far 
I was using some flags (regular variables) or QWaitCondition in endless loop 
inside run() function, but I found it cumbersome when dealing with many jobs 
to do.

In the end, what would be the best way?
What I need to implement in app is like this.
When it initialize app, it queries all devices through rs232 which takes about 
10 seconds. This is easy - put all work inside run() of a rs232 thread and 
receive signals notifying about every device. Such a general checking is 
invoked every five minutes, so I have function that sets variables like 
checkSomething and starts rs232 thread (if its not working). However, between 
these general checkings, if user move QDial (or press button which has 
autoRepeat) on the gui it has to send signals to change something in device, 
because it takes about 100 miliseconds for rs232 to accomplish single change, 
and QDial has tracking enabled I need rs232 to buffer this subsequent changes 
and apply them to device without gui freezing. So, the mechanism with 
queueing events for rs232 (which works in separate thread) is very attractive 
to me, but question: am I missing something, or should I go stright to number 
2 solution?

best regards
Marek

>
> --
> J-P Nurmi
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest