Starting QT GUI in a seperate Thread

[bbui210]

Hello everyone,

I am continuing my talk from another thread and thought that this is a whole other issue in itself.

I would like to start my main application and create two threads, one to process some data and one to initialize and start the QT GUI. (Why I don't just make my GUI the core of the application is another story).

I am able to do this and compile everything, however, the GUI Thread seems to take over and all other threads seem to be blocked (or not getting any cpu time), including the main thread.

Here's a sample of my code:

void *initUI(char *argv[]) {
	hpgeUI(argv);  //this function does all the QApplication, exec() stuff
	return 0;
}
 
void *process() {
	printf("This is the process thread\n");
	return 0;
}
 
int main(int argc, char *argv[])
{
 
	pthread_t guithread, process;
	pthread_create(&guithread, NULL, initUI(argv), 0);
       //CHECK PT 1
	pthread_create(&process, NULL, process, 0);
	while(1)
	{
	//do something here
	}
	return 0;
}

void *initUI(char *argv[]) {
	hpgeUI(argv);  //this function does all the QApplication, exec() stuff
	return 0;
}

void *process() {
	printf("This is the process thread\n");
	return 0;
}

int main(int argc, char *argv[])
{
	
	pthread_t guithread, process;
	pthread_create(&guithread, NULL, initUI(argv), 0);
       //CHECK PT 1
	pthread_create(&process, NULL, process, 0);
	while(1)
	{
	//do something here
	}
	return 0;
}

To copy to clipboard, switch view to plain text mode 

Any ideas as to why this is happening? The GUI is showing up and seems to hijack all the resources of the application; no other threads are created and CHECK PT 1 is not reached.

Regards,
BB

[wysota]

Any particular reason for using pthreads instead of QThread? Why not put your while loop in a worker thread (or get rid of it which is probably possible) and process the gui in the main thread?

[spirit]

you can't create widgets in a non-GUI thread, the GUI-thread is main the thread. you need to send events or signals to main thread from another threads to create some widget.

[wysota]

Actually the GUI thread is the thread the application object lives in. It doesn't have to be the "main" thread.

[bbui210]

Actually the GUI thread is the thread the application object lives in. It doesn't have to be the "main" thread.

From experience this looks to be true, however, the documentation does say that

the QCoreApplication::exec() must always be called from the main thread (the thread that executes main())

Is this because the QCoreApplicationtakes over all other threads and manages a subset of it's own? Meaning any other thread that is running outside or created outside of the QCoreApplicationis blocked? That is what seems to be going on.

And to clear things up, I'm not creating widgets or doing any other graphical manipulation in the other threads. I am creating a thread to start the QApplicationand all the related graphical elements, then starting a second thread that does some processing.

Any particular reason for using pthreads instead of QThread? Why not put your while loop in a worker thread (or get rid of it which is probably possible) and process the gui in the main thread?

The reason why I don't just create a QThreadwithin QApplicationis because I am not able to modify the code that goes into this "processing" thread, except for the starting of the new thread and passing a few functions to pipe data through. It is a large C program which will be built outside of all the GUI stuff and I've created a static library for the GUI itself. So far it works except for the issue above.

Thank you for all your help.

Regards,
BB

[tinsuke]

Got it!

The CP 1 will never be reached because when calling pthread_create for the 1st time, you're not passing initUI to the function that will create the thread, you're CALLING it!!!

The right code would be like this:

pthread_create(&guithread, NULL, initUI, argv);

pthread_create(&guithread, NULL, initUI, argv);

To copy to clipboard, switch view to plain text mode 

Passing initUI(argv) to pthread_create does not pass the pointer to the function initUI, but its resultant void* by effectively calling initUI(argv).

Best regards

[wysota]

From experience this looks to be true, however, the documentation does say that (...)

It's been known to work fine.

The reason why I don't just create a QThreadwithin QApplicationis because I am not able to modify the code that goes into this "processing" thread, except for the starting of the new thread and passing a few functions to pipe data through. It is a large C program which will be built outside of all the GUI stuff and I've created a static library for the GUI itself. So far it works except for the issue above.

There are different design concepts available, so you can surely do it in another way. Your GUI can even be a separate process to the data processor and in this situation that would probably be the best solution.

[mayanka_medhe]

Hi!
I am trying to do almost the same thing as @bbui210 but I am using std::thread. I am facing the issue that it is behaving sequential and not parallel. My QT GUI (QT application) is in the main thread. My code structure is like below-

int process(arguments)
{
//processing and saving the data in a file
}
 
int main(arguments)
{
//GUI is called which accesses the file
std::thread threadObj(process, arguments_of_process);
threadObj.join();
}

int process(arguments)
{
//processing and saving the data in a file
}

int main(arguments)
{
//GUI is called which accesses the file
std::thread threadObj(process, arguments_of_process);
threadObj.join();
}

To copy to clipboard, switch view to plain text mode 

I want my GUI to keep updating itself as file changes. My main reason for using std::thread was that it was easier to use and also I had to pass arguments to the function. Can someone tell me what is wrong with my code?

Thanks!!

[d_stranz]

This isn't code, it's pseudocode. If you want us to help diagnose problems with code, post a minimum working example of REAL code that demonstrates the problem. Otherwise, you are just wasting everyone's time.