Qt-interest Archive, March 2007
Thread Problem with signal->slot connections
Message 1 in thread
Dear all,
I have a strange problem with an app that uses a lot of threads (5). (I use
qt 4.2.1)
The app should listen to the serial port until something happens there (I
use WaitCommTimeout, WIN32 COM). Because the program execution is freezed as
long as the waitcommtimeout listens to the port, i shifted this funktion to
another thread.
Now I have the following situation: A UserInterface thread that generates an
instance of "mainthread". This thread itself is generating the different
worker threads and is doing the synchronisation between them. Therefore in
the mainthread i did a lot of signal->slot connections. One connection is
for example the call to watch() if a signal is emitted in mainthread. Watch
itself is running in a worker thread and is performing the listening to the
serial port. After I connected everything and also started all the threads i
try to test it and my app freezes everytime the signal dowatch() is emitted.
If I send a "pseudo" signal to the serial port, then the waitcommtimeout
gets his event and the app is running normally..but this is not a solution
to my problem :( Only the worker thread should be freezed and nothing else
:(
Can anybody of you help me out on how i can solve this problem?
Message 2 in thread
Joachim Zettler wrote:
> Dear all,
>
> I have a strange problem with an app that uses a lot of threads (5).
> (I use qt 4.2.1)
>
> The app should listen to the serial port until something happens there
> (I use WaitCommTimeout, WIN32 COM). Because the program execution is
> freezed as long as the waitcommtimeout listens to the port, i shifted
> this funktion to another thread.
>
> Now I have the following situation: A UserInterface thread that
> generates an instance of "mainthread". This thread itself is
> generating the different worker threads and is doing the
> synchronisation between them. Therefore in the mainthread i did a lot
> of signal->slot connections. One connection is for example the call to
> watch() if a signal is emitted in mainthread. Watch itself is running
> in a worker thread and is performing the listening to the serial port.
> After I connected everything and also started all the threads i try to
> test it and my app freezes everytime the signal dowatch() is emitted.
> If I send a "pseudo" signal to the serial port, then the
> waitcommtimeout gets his event and the app is running normally..but
> this is not a solution to my problem :( Only the worker thread should
> be freezed and nothing else :(
>
> Can anybody of you help me out on how i can solve this problem?
>
Okay, it sounds like your creating the listening objects in the thread
constructor (or even worse, creating the signals as part of the thread
object). What you need to do is create a dedicated object that has the
actual slots. Create these objects inside the run function of the
thread, and then these will have their event loops tied to the actual
thread. You can create proxy slots in the thread object, that can then
forward on the slot call onto the internal object. Basically, to
reiterate, a thread needs to have its event loop on the main/creating
thread, and any object created in the threads constructor will also have
its event loop on the main/creating thread. Any object created inside
the run event however will have it's event loop in the thread itself.
Hope this helps.
--
[ signature omitted ]
Message 3 in thread
Thank you for your answer Bill,
yes in fact at the moment I just start my mainthread in the userinterface
class by creating the instance of mainthread and then directly
mainthread->start()
Inside mainthread in the constructor I generate myself the instances of the
other thread-classes (might this already be the problem??)
So to summarize: Bevore I do the first start() all instances have been
created through the creation of the mainthread instance.
To start the other threads...I then click a button inside the ui-class and
use the signal to start a function inside mainthread that is just starting
all other threads. These connections are set up inside mainthread.
Best regards,
Joachim
2007/3/27, Bill KING <bill.king@xxxxxxxxxxxxx>:
>
> Joachim Zettler wrote:
> > Dear all,
> >
> > I have a strange problem with an app that uses a lot of threads (5).
> > (I use qt 4.2.1)
> >
> > The app should listen to the serial port until something happens there
> > (I use WaitCommTimeout, WIN32 COM). Because the program execution is
> > freezed as long as the waitcommtimeout listens to the port, i shifted
> > this funktion to another thread.
> >
> > Now I have the following situation: A UserInterface thread that
> > generates an instance of "mainthread". This thread itself is
> > generating the different worker threads and is doing the
> > synchronisation between them. Therefore in the mainthread i did a lot
> > of signal->slot connections. One connection is for example the call to
> > watch() if a signal is emitted in mainthread. Watch itself is running
> > in a worker thread and is performing the listening to the serial port.
> > After I connected everything and also started all the threads i try to
> > test it and my app freezes everytime the signal dowatch() is emitted.
> > If I send a "pseudo" signal to the serial port, then the
> > waitcommtimeout gets his event and the app is running normally..but
> > this is not a solution to my problem :( Only the worker thread should
> > be freezed and nothing else :(
> >
> > Can anybody of you help me out on how i can solve this problem?
> >
> Okay, it sounds like your creating the listening objects in the thread
> constructor (or even worse, creating the signals as part of the thread
> object). What you need to do is create a dedicated object that has the
> actual slots. Create these objects inside the run function of the
> thread, and then these will have their event loops tied to the actual
> thread. You can create proxy slots in the thread object, that can then
> forward on the slot call onto the internal object. Basically, to
> reiterate, a thread needs to have its event loop on the main/creating
> thread, and any object created in the threads constructor will also have
> its event loop on the main/creating thread. Any object created inside
> the run event however will have it's event loop in the thread itself.
>
> Hope this helps.
>
> --
> Bill King, Software Engineer
> Trolltech, Brisbane Technology Park
> 26 Brandl St, Eight Mile Plains,
> QLD, Australia, 4113
> Tel + 61 7 3219 9906 (x137)
> Fax + 61 7 3219 9938
> mobile: 0423 532 733
>
>
Message 4 in thread
Yes, the problem is that each QThread object will handle the events on
the thread they were created on. So, currently, all the subthreads, will
execute their slots and signals in mainthread. To get around this,
create internal objects inside the threads, that handle the work. The
threads then just become proxies to these inner threads. It's kinda
complicated I know, but, if you think about it, thread signals like
"finished" and "terminated", can't be fired off inside the thread, as
well the thread will have already disappeared by then. So the QThread
object needs to be based in the thread that created it.
Joachim Zettler wrote:
> Thank you for your answer Bill,
>
> yes in fact at the moment I just start my mainthread in the
> userinterface class by creating the instance of mainthread and then
> directly mainthread->start()
>
> Inside mainthread in the constructor I generate myself the instances
> of the other thread-classes (might this already be the problem??)
>
> So to summarize: Bevore I do the first start() all instances have been
> created through the creation of the mainthread instance.
>
> To start the other threads...I then click a button inside the ui-class
> and use the signal to start a function inside mainthread that is just
> starting all other threads. These connections are set up inside
> mainthread.
>
> Best regards,
>
> Joachim
>
> 2007/3/27, Bill KING <bill.king@xxxxxxxxxxxxx
> <mailto:bill.king@xxxxxxxxxxxxx>>:
>
> Joachim Zettler wrote:
> > Dear all,
> >
> > I have a strange problem with an app that uses a lot of threads (5).
> > (I use qt 4.2.1)
> >
> > The app should listen to the serial port until something happens
> there
> > (I use WaitCommTimeout, WIN32 COM). Because the program execution is
> > freezed as long as the waitcommtimeout listens to the port, i
> shifted
> > this funktion to another thread.
> >
> > Now I have the following situation: A UserInterface thread that
> > generates an instance of "mainthread". This thread itself is
> > generating the different worker threads and is doing the
> > synchronisation between them. Therefore in the mainthread i did
> a lot
> > of signal->slot connections. One connection is for example the
> call to
> > watch() if a signal is emitted in mainthread. Watch itself is
> running
> > in a worker thread and is performing the listening to the serial
> port.
> > After I connected everything and also started all the threads i
> try to
> > test it and my app freezes everytime the signal dowatch() is
> emitted.
> > If I send a "pseudo" signal to the serial port, then the
> > waitcommtimeout gets his event and the app is running normally..but
> > this is not a solution to my problem :( Only the worker thread
> should
> > be freezed and nothing else :(
> >
> > Can anybody of you help me out on how i can solve this problem?
> >
> Okay, it sounds like your creating the listening objects in the thread
> constructor (or even worse, creating the signals as part of the thread
> object). What you need to do is create a dedicated object that has
> the
> actual slots. Create these objects inside the run function of the
> thread, and then these will have their event loops tied to the actual
> thread. You can create proxy slots in the thread object, that can then
> forward on the slot call onto the internal object. Basically, to
> reiterate, a thread needs to have its event loop on the main/creating
> thread, and any object created in the threads constructor will
> also have
> its event loop on the main/creating thread. Any object created inside
> the run event however will have it's event loop in the thread itself.
>
> Hope this helps.
>
> --
> Bill King, Software Engineer
> Trolltech, Brisbane Technology Park
> 26 Brandl St, Eight Mile Plains,
> QLD, Australia, 4113
> Tel + 61 7 3219 9906 (x137)
> Fax + 61 7 3219 9938
> mobile: 0423 532 733
>
>
--
[ signature omitted ]
Message 5 in thread
Bill,
Do you have a good document describing all the complicated stuff of QThread
?
(in addition to the documentation)
Jagath
On 3/28/07, Bill KING <bill.king@xxxxxxxxxxxxx> wrote:
>
> Yes, the problem is that each QThread object will handle the events on
> the thread they were created on. So, currently, all the subthreads, will
> execute their slots and signals in mainthread. To get around this,
> create internal objects inside the threads, that handle the work. The
> threads then just become proxies to these inner threads. It's kinda
> complicated I know, but, if you think about it, thread signals like
> "finished" and "terminated", can't be fired off inside the thread, as
> well the thread will have already disappeared by then. So the QThread
> object needs to be based in the thread that created it.
>
> Joachim Zettler wrote:
> > Thank you for your answer Bill,
> >
> > yes in fact at the moment I just start my mainthread in the
> > userinterface class by creating the instance of mainthread and then
> > directly mainthread->start()
> >
> > Inside mainthread in the constructor I generate myself the instances
> > of the other thread-classes (might this already be the problem??)
> >
> > So to summarize: Bevore I do the first start() all instances have been
> > created through the creation of the mainthread instance.
> >
> > To start the other threads...I then click a button inside the ui-class
> > and use the signal to start a function inside mainthread that is just
> > starting all other threads. These connections are set up inside
> > mainthread.
> >
> > Best regards,
> >
> > Joachim
> >
> > 2007/3/27, Bill KING <bill.king@xxxxxxxxxxxxx
> > <mailto:bill.king@xxxxxxxxxxxxx>>:
> >
> > Joachim Zettler wrote:
> > > Dear all,
> > >
> > > I have a strange problem with an app that uses a lot of threads
> (5).
> > > (I use qt 4.2.1)
> > >
> > > The app should listen to the serial port until something happens
> > there
> > > (I use WaitCommTimeout, WIN32 COM). Because the program execution
> is
> > > freezed as long as the waitcommtimeout listens to the port, i
> > shifted
> > > this funktion to another thread.
> > >
> > > Now I have the following situation: A UserInterface thread that
> > > generates an instance of "mainthread". This thread itself is
> > > generating the different worker threads and is doing the
> > > synchronisation between them. Therefore in the mainthread i did
> > a lot
> > > of signal->slot connections. One connection is for example the
> > call to
> > > watch() if a signal is emitted in mainthread. Watch itself is
> > running
> > > in a worker thread and is performing the listening to the serial
> > port.
> > > After I connected everything and also started all the threads i
> > try to
> > > test it and my app freezes everytime the signal dowatch() is
> > emitted.
> > > If I send a "pseudo" signal to the serial port, then the
> > > waitcommtimeout gets his event and the app is running
> normally..but
> > > this is not a solution to my problem :( Only the worker thread
> > should
> > > be freezed and nothing else :(
> > >
> > > Can anybody of you help me out on how i can solve this problem?
> > >
> > Okay, it sounds like your creating the listening objects in the
> thread
> > constructor (or even worse, creating the signals as part of the
> thread
> > object). What you need to do is create a dedicated object that has
> > the
> > actual slots. Create these objects inside the run function of the
> > thread, and then these will have their event loops tied to the
> actual
> > thread. You can create proxy slots in the thread object, that can
> then
> > forward on the slot call onto the internal object. Basically, to
> > reiterate, a thread needs to have its event loop on the
> main/creating
> > thread, and any object created in the threads constructor will
> > also have
> > its event loop on the main/creating thread. Any object created
> inside
> > the run event however will have it's event loop in the thread
> itself.
> >
> > Hope this helps.
> >
> > --
> > Bill King, Software Engineer
> > Trolltech, Brisbane Technology Park
> > 26 Brandl St, Eight Mile Plains,
> > QLD, Australia, 4113
> > Tel + 61 7 3219 9906 (x137)
> > Fax + 61 7 3219 9938
> > mobile: 0423 532 733
> >
> >
>
>
> --
> Bill King, Software Engineer
> Trolltech, Brisbane Technology Park
> 26 Brandl St, Eight Mile Plains,
> QLD, Australia, 4113
> Tel + 61 7 3219 9906 (x137)
> Fax + 61 7 3219 9938
> mobile: 0423 532 733
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Message 6 in thread
Jagath Weerasinghe wrote:
> Bill,
>
> Do you have a good document describing all the complicated stuff of
> QThread ?
> (in addition to the documentation)
>
> Jagath
>
> On 3/28/07, *Bill KING * <bill.king@xxxxxxxxxxxxx
> <mailto:bill.king@xxxxxxxxxxxxx>> wrote:
>
> Yes, the problem is that each QThread object will handle the events on
> the thread they were created on. So, currently, all the
> subthreads, will
> execute their slots and signals in mainthread. To get around this,
> create internal objects inside the threads, that handle the work. The
> threads then just become proxies to these inner threads. It's kinda
> complicated I know, but, if you think about it, thread signals like
> "finished" and "terminated", can't be fired off inside the thread, as
> well the thread will have already disappeared by then. So the QThread
> object needs to be based in the thread that created it.
>
> Joachim Zettler wrote:
> > Thank you for your answer Bill,
> >
> > yes in fact at the moment I just start my mainthread in the
> > userinterface class by creating the instance of mainthread and then
> > directly mainthread->start()
> >
> > Inside mainthread in the constructor I generate myself the instances
> > of the other thread-classes (might this already be the problem??)
> >
> > So to summarize: Bevore I do the first start() all instances
> have been
> > created through the creation of the mainthread instance.
> >
> > To start the other threads...I then click a button inside the
> ui-class
> > and use the signal to start a function inside mainthread that is
> just
> > starting all other threads. These connections are set up inside
> > mainthread.
> >
> > Best regards,
> >
> > Joachim
> >
> > 2007/3/27, Bill KING <bill.king@xxxxxxxxxxxxx
> <mailto:bill.king@xxxxxxxxxxxxx>
> > <mailto:bill.king@xxxxxxxxxxxxx <mailto:bill.king@xxxxxxxxxxxxx>>>:
> >
> > Joachim Zettler wrote:
> > > Dear all,
> > >
> > > I have a strange problem with an app that uses a lot of
> threads (5).
> > > (I use qt 4.2.1)
> > >
> > > The app should listen to the serial port until something
> happens
> > there
> > > (I use WaitCommTimeout, WIN32 COM). Because the program
> execution is
> > > freezed as long as the waitcommtimeout listens to the port, i
> > shifted
> > > this funktion to another thread.
> > >
> > > Now I have the following situation: A UserInterface thread
> that
> > > generates an instance of "mainthread". This thread itself is
> > > generating the different worker threads and is doing the
> > > synchronisation between them. Therefore in the mainthread
> i did
> > a lot
> > > of signal->slot connections. One connection is for example the
> > call to
> > > watch() if a signal is emitted in mainthread. Watch itself is
> > running
> > > in a worker thread and is performing the listening to the
> serial
> > port.
> > > After I connected everything and also started all the
> threads i
> > try to
> > > test it and my app freezes everytime the signal dowatch() is
> > emitted.
> > > If I send a "pseudo" signal to the serial port, then the
> > > waitcommtimeout gets his event and the app is running
> normally..but
> > > this is not a solution to my problem :( Only the worker thread
> > should
> > > be freezed and nothing else :(
> > >
> > > Can anybody of you help me out on how i can solve this
> problem?
> > >
> > Okay, it sounds like your creating the listening objects in
> the thread
> > constructor (or even worse, creating the signals as part of
> the thread
> > object). What you need to do is create a dedicated object
> that has
> > the
> > actual slots. Create these objects inside the run function
> of the
> > thread, and then these will have their event loops tied to
> the actual
> > thread. You can create proxy slots in the thread object,
> that can then
> > forward on the slot call onto the internal object. Basically, to
> > reiterate, a thread needs to have its event loop on the
> main/creating
> > thread, and any object created in the threads constructor will
> > also have
> > its event loop on the main/creating thread. Any object
> created inside
> > the run event however will have it's event loop in the
> thread itself.
> >
> > Hope this helps.
> >
> > --
> > Bill King, Software Engineer
> > Trolltech, Brisbane Technology Park
> > 26 Brandl St, Eight Mile Plains,
> > QLD, Australia, 4113
> > Tel + 61 7 3219 9906 (x137)
> > Fax + 61 7 3219 9938
> > mobile: 0423 532 733
> >
> >
>
>
> --
> Bill King, Software Engineer
> Trolltech, Brisbane Technology Park
> 26 Brandl St, Eight Mile Plains,
> QLD, Australia, 4113
> Tel + 61 7 3219 9906 (x137)
> Fax + 61 7 3219 9938
> mobile: 0423 532 733
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx
> <mailto:qt-interest-request@xxxxxxxxxxxxx> with "unsubscribe" in
> the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
Sadly no, I had to find this out the hard way, but I'll put it forward
to the documentation team. So, it may get into the next release.
--
[ signature omitted ]
Message 7 in thread
Just making sure, but if you haven't read the below link, may be
worthwhile. It's probably the most comprehensive collection of
information on QThread and friends.
http://doc.trolltech.com/4.3/threads.html
Jagath Weerasinghe wrote:
> Bill,
>
> Do you have a good document describing all the complicated stuff of
> QThread ?
> (in addition to the documentation)
>
> Jagath
>
--
[ signature omitted ]
Message 8 in thread
"Jagath Weerasinghe" <jagfossqtopia@xxxxxxxxx> wrote in message
news:a0faa3460703280402s6dd42931s4e15d61049336a31@xxxxxxxxxxxxxxxxx
> Bill,
>
> Do you have a good document describing all the complicated stuff of
> QThread
> ?
> (in addition to the documentation)
>
> Jagath
The complicated fact about QThread in that respect is that it's not
complicated :)
A QObject is owned by the thread that creates it. The event loop in that
"owner" thread is responsible for dispatching events to the QObjects owned
by the thread. So every QObject gets its event handlers and
"queued-connected" slots called by the thread that owns it.
QThread is a QObject, so all the above applies to QThread. Since the QThread
instance needs to exist before you can start the thread by calling start()
on it, QThread cannot be owned by the thread that it starts. Think about
QThread::run() as another main() function - in main you create the objects
that respond to event in the main thread, in run() you create the objects
that respond to events in your worker thread.
You can use moveToThread() of course, but that easily leads to poor design
that is difficult to refactor.
Volker
--
[ signature omitted ]
Message 9 in thread
Hi Bill,
ok, basically i can follow you :)
Thank you once again for your help and good explaination.
I would also be interested in additional information concerning the qthread
stuff.
Best regards,
Joachim
2007/3/28, Bill KING < bill.king@xxxxxxxxxxxxx>:
>
> Yes, the problem is that each QThread object will handle the events on
> the thread they were created on. So, currently, all the subthreads, will
> execute their slots and signals in mainthread. To get around this,
> create internal objects inside the threads, that handle the work. The
> threads then just become proxies to these inner threads. It's kinda
> complicated I know, but, if you think about it, thread signals like
> "finished" and "terminated", can't be fired off inside the thread, as
> well the thread will have already disappeared by then. So the QThread
> object needs to be based in the thread that created it.
>
> Joachim Zettler wrote:
> > Thank you for your answer Bill,
> >
> > yes in fact at the moment I just start my mainthread in the
> > userinterface class by creating the instance of mainthread and then
> > directly mainthread->start()
> >
> > Inside mainthread in the constructor I generate myself the instances
> > of the other thread-classes (might this already be the problem??)
> >
> > So to summarize: Bevore I do the first start() all instances have been
> > created through the creation of the mainthread instance.
> >
> > To start the other threads...I then click a button inside the ui-class
> > and use the signal to start a function inside mainthread that is just
> > starting all other threads. These connections are set up inside
> > mainthread.
> >
> > Best regards,
> >
> > Joachim
> >
> > 2007/3/27, Bill KING <bill.king@xxxxxxxxxxxxx
> > <mailto: bill.king@xxxxxxxxxxxxx>>:
> >
> > Joachim Zettler wrote:
> > > Dear all,
> > >
> > > I have a strange problem with an app that uses a lot of threads
> (5).
> > > (I use qt 4.2.1)
> > >
> > > The app should listen to the serial port until something happens
> > there
> > > (I use WaitCommTimeout, WIN32 COM). Because the program execution
> is
> > > freezed as long as the waitcommtimeout listens to the port, i
> > shifted
> > > this funktion to another thread.
> > >
> > > Now I have the following situation: A UserInterface thread that
> > > generates an instance of "mainthread". This thread itself is
> > > generating the different worker threads and is doing the
> > > synchronisation between them. Therefore in the mainthread i did
> > a lot
> > > of signal->slot connections. One connection is for example the
> > call to
> > > watch() if a signal is emitted in mainthread. Watch itself is
> > running
> > > in a worker thread and is performing the listening to the serial
> > port.
> > > After I connected everything and also started all the threads i
> > try to
> > > test it and my app freezes everytime the signal dowatch() is
> > emitted.
> > > If I send a "pseudo" signal to the serial port, then the
> > > waitcommtimeout gets his event and the app is running
> normally..but
> > > this is not a solution to my problem :( Only the worker thread
> > should
> > > be freezed and nothing else :(
> > >
> > > Can anybody of you help me out on how i can solve this problem?
> > >
> > Okay, it sounds like your creating the listening objects in the
> thread
> > constructor (or even worse, creating the signals as part of the
> thread
> > object). What you need to do is create a dedicated object that has
> > the
> > actual slots. Create these objects inside the run function of the
> > thread, and then these will have their event loops tied to the
> actual
> > thread. You can create proxy slots in the thread object, that can
> then
> > forward on the slot call onto the internal object. Basically, to
> > reiterate, a thread needs to have its event loop on the
> main/creating
> > thread, and any object created in the threads constructor will
> > also have
> > its event loop on the main/creating thread. Any object created
> inside
> > the run event however will have it's event loop in the thread
> itself.
> >
> > Hope this helps.
> >
> > --
> > Bill King, Software Engineer
> > Trolltech, Brisbane Technology Park
> > 26 Brandl St, Eight Mile Plains,
> > QLD, Australia, 4113
> > Tel + 61 7 3219 9906 (x137)
> > Fax + 61 7 3219 9938
> > mobile: 0423 532 733
> >
> >
>
>
> --
> Bill King, Software Engineer
> Trolltech, Brisbane Technology Park
> 26 Brandl St, Eight Mile Plains,
> QLD, Australia, 4113
> Tel + 61 7 3219 9906 (x137)
> Fax + 61 7 3219 9938
> mobile: 0423 532 733
>
>
