[Qt-interest] QApplication on separate thread...
Eric Clark
eclark at ara.com
Wed Jun 23 04:49:36 CEST 2010
> -----Original Message-----
> From: qt-interest-bounces at trolltech.com [mailto:qt-interest-
> bounces at trolltech.com] On Behalf Of Arnold Krille
> Sent: Tuesday, June 22, 2010 3:37 PM
> To: qt-interest at trolltech.com
> Subject: Re: [Qt-interest] QApplication on separate thread...
>
> On Tuesday 22 June 2010 20:55:10 Andre Somers wrote:
> > Op 22-6-2010 19:35, Eric Clark schreef:
> > > I have a non-Qt application that loads a Qt application. The non-qt
> > > application would like to instantiate and start the Qt application
> > > on a separate thread than the main thread in which it resides. I am
> > > getting some errors associated with sending signals to objects on
> > > different threads. I was wondering if anyone could tell me if it is
> > > possible to have a QApplication that resides on a thread different
> > > than that of the main application? Or is it a requirement that the
> > > QApplication reside on the application's main thread?
> > The main application needs to be in the main thread, as do all paint
> > operations.
>
> Nope. All painting operations have to happen in the thread that
> instantiates the X-connections. Which is the thread that instantiates
> QApplication. That doesn't necessarily have to be the apps main-
> process.
That is good to hear! Then I just need to figure out what object is getting instantiated on the wrong thread, but that really helps me look in the right direction.
>
> > But... I don't get your requirement at all. If you have two
> > applications anyway, they run in separate processes already. A thread
> > represents parallel code paths *inside* a process. How do you
> envision
> > running an application in another thread?
>
> The old way: starting of a thread and replace it with another app.
> Don't remember the actual posix functions...
Exactly! This application is actually a windows application so it will most likely use the windows thread API, but you get the point.
The non-qt application is its own process, yes, but it links to the libraries of my qt application and tries to instantiate the QApplication on a separate thread within in its own process. They are NOT two separate processes. It is not started by calling an executable.
>
> Arnold
Thank you for your help! Assuming you are correct about where the application resides (which was my assumption in the first place), this should give me a little guidance in debugging the problem. At least I know it is possible. Thank You Again!
Eric
More information about the Qt-interest-old
mailing list