My application uses ZModem protocol for communication.
From main thread, I am created second thread for progess bar. So, main thread is working on communication and second thread is for extra work. They are communicated through global variable.
If they are on same thread then main windows communication will be blocked.
Now, because of two thread they cannot uses DoModal() with each other.
What can i do for DoModal() this two thread or there is any option for doing it on one thread but communicating same way?
Control all windows from the main thread. Use a second thread for the communication operations.
Related
I've got a problem with modifying the port number while the socket is listening for python clients. This is for an application on Windows.
Does anyone know if it's possible to stop a port from listening, from the main thread, while the port listening is in another thread?
The socket lives in its own thread, not the main thread. And I can not modify a socket from other thread than current thread. I tried by using signals and slots but it did not work. I am using the thread-worker approach currently. Does any one have any suggestions?
The target thread must be an unmodified QThread, i.e. it must spin an event loop.
The socket I/O should reside in a QObject that you have moved to that thread.
You can then easily execute arbitrary code in the target thread, invoked from any other thread.
Having some confusion over what counts as the "Main" thread in this situation.
I have QT running in my first thread which is blocking. I want to run SDL2 in a secondary thread, with all calls and initilisation isolated to this thread.
Will this allow SDL2 to run correctly and stable as the Documentation states it needs to be in the main thread? Also this question SDL2 two windows in different threads states you can't use certain SDL2 functions outside the "main" thread.
In this case is the main thread, as far as SDL2 is concerned, the first thread containing QT, or the second thread SDL2 was initilised in?
This is just a guess, but in linux the concept of a "main thread" is the first thread in a process. Here's how to see if a thread is the main thread: Check if current thread is main thread
So to answer your question, you can't have QT running as the first thread and SDL2 running as the second. You'll either need:
Two processes. Then, each is running a main thread
Run SDL as the first process (the main thread) and QT as a subthread (if QT allows for this)
More precisely, the question should be:
What's the difference between connecting the signal QTimer::timeout to my working function and creating a worker thread with QThread?
I am writing a program which receives streaming data in main thread (the signal is generated by QIODevice::readread())and processes them concurrently. For now I start a QTimer constantly firing signal QTimer::timeout, and the signal is connected to a working function in main thread which does the data processing stuff. This is how I achieve the concurrency.
I wonder if this approach different from creating another thread with QThread, since the idea I've found in this topic is very simliar to what I've done. The only difference is that the accepted answer creates another thread and moves timer and worker class on it. Besides the difference, I can't see any necessity of using a thread in my case.
In my case (receiving data in main thread and processing them concurrently), am I doing OK using QTimer or should I create a QThread? I am quite new to multi-threading, and if I misunderstand something, please help correct me. Thank you.
[Edit]:
I don't know what's the difference/advantage of creating a new thread to process the data. For now, everything is doing in one thread: I keep storing data in a queue and dequeue them one by one in a function triggered by QTimer::timeout.
What's the difference between connecting the signal QTimer::timeout to my working
function and creating a worker thread with QThread?
When you connect some signal/slot pair from the objects which has the same thread affinity, then the connection is direct. What it means is in your case, the main thread creates the timer, and also contains the slot, so the signal will be emitted in the main thread and also will be processed in the main thread (as the slot is also in the main thread).
When you connect some signal/slot pair from the objects which has the different thread affinity, then the connection is queued. That means signal emission and slot execution will run in different threads.
You are not really achieving concurrency, the timer signal and processing slot are executing in main thread sequentially.
So here are your options:
If you want to process data in main thread, current code is ok.
If you want to emit timeout in main thread and process data in different thread then create new class with the processing method and use moveToThread with object of that class.
The link you provided really has a different situation. In your case (correct me if I am wrong), you process data only when data is available, not just after a specified time. Your situation is much like traditional producer/consumer problem. My proposal is to not use QTimer at all. Instead create a new class with a slotwhich will process data. Then emit a signal from main thread when data is available, and connect if to the processing slot. You will achieve real concurrency. In this case you will need to implement locking for shared data access, it is easy in Qt, you can just use QMutexLocker
First, a little background:
One of the fundamental ideas behind threads is that a thread can only do one thing at a time. It may be updating the GUI, or processing data, or communicating with a remote server, but it can't be doing all those things at once.
That's where multi-threading comes in. You probably want your computer to be doing many things at once (watching videos, browsing the web, listening to music, and writing code all at the same time). The computer allows you to do that by scheduling each of these tasks on a separate threads and switching between them in periodic intervals.
In the old days, before multi-core processors, this was achieved solely by multitasking (the processor would interrupt the currently executing thread, switch to another thread context and execute the other thread for a while before switching again). With modern processors, you can have several threads executing at the EXACT same time, one on each core. This is typically referred to as multiprocessing.
Now, back to your question:
A thread can only do one thing at a time and, if you use a timer, you are using the main (AKA GUI) thread to process your data. This thread is typically responsible for responding to OS events and updating the GUI (hence GUI thread). If you don't have a lot of data to process, it's typically OK to do so on the GUI thread. However, if the data processing time has a chance of growing, it is recommended to execute such processing on a separate thread to make sure that the UI remains responsive (and so that you don't get the annoying "Your program is not responding" message from the OS). Basically, if data processing can take longer than ~200ms, it is recommended to execute the processing on a separate thread so that the user doesn't feel like the GUI is "stuck".
Background:
I have two GUI threads: Main and SendEmail in an MFC/Win32 application.
Normally, the main thread spawns the send email thread and continues to run. The send email thread tells the main thread's window to stay disabled and captures the mouse, and when it exits, it enables the main thread's window and releases the mouse.
This gives the user the work-flow of the main application is disabled while they're sending an email. The need to do this in a separate thread has to do with problems with MAPI and Outlook since 2010, where it would lock up the app if it was executed on the main thread.
However, if it so happens that the main application does exit while the send mail thread is still running, the process crashes (the send mail thread tries to enable the main thread's window which no longer exists...)
Goal:
To have the main thread wait for the send mail thread to terminate before terminating
Sticking point:
Currently, the email thread self-destructs (there is no memory management, since it calls delete on itself when its run method finishes). But I want the main thread to keep a reference to this thread so that it can wait on a live one at exit.
I cannot use a weak reference, I don't think, because the main thread really should wait on this thread object (threads are inherently waitable), so I don't want the object that represents this thread to self-destruct while the min thread holds it.
I can use a shared pointer - so that both the application and the running thread effectively keep the thread object alive... but then how to delete the application's copy of the thread object when the thread is finished? (I don't want the thread object to keep on existing for no purpose).
I could post a message from the email thread to the main app thread saying "I'm dying" so that the main thread immediately waits for the thread to terminate and then deletes its reference...
Any better ideas?
I'm just curious as to to how to implement multi-threading without using a Windows API WaitFor* function that stops the program until the thread has returned. What's the point of using threads if they stop the main application from being resized or moved etc.?
Is there any form of windows messaging with threading, which will allow me to call my thread function and then return, and handle the return values of the thread when it finishes running?
If you want your UI thread to know when a task thread has finished it's task then you could have your task thread post a (custom - WM_USER and above) message to your main window (along with thread id plus the handle). And the window proc of the main window can know that a particular task thread has finished it's task. This way the UI thread does not have to wait actively (using WaitFor*) on the thread(s) object.
You can use MsgWaitForMultipleObjectsEx to wait for the thread to finish and also process messages at the same time.
Have a look at std::thread, boost::thread, just::thread, for multithreading in general for c++.
But about Windows messaging win32 and MFC, the MSDN states explicitely that it is not multithread, it is monothread. ( Undefined behaviour is to be expected if multithreading is used)
For asynchronous message emited in other thread than the main application window thread, you should use ::PostMessage(), that will insert message events in the monothread message pump of the mono threaded window.
WaitForSingleObject can be non-blocking, just pass zero timeout as second parameter:
// Check is thread has been finished
if(::WaitForSingleObject(threadHandle, 0) == WAIT_OBJECT_0)
{
// Process results
...
}
You will need to periodically check this condition, e.g. on timer or after processing any message in message loop.
Or you can use MsgWaitForMultipleObjectsEx. It will unblock and return when some message/input event occured in calling thread message queue.
As other answers mentioned there is another way - using Windows asynchronously posted message to signal that thread has done its work. This way has disadvantage - the working thread must know target window or thread to post message to. This dependency complicates design and raises issues about checking thread/window lifetime. To avoid it message broadcasting (PostMessage(HWND_BROADCAST,...))
can be used, but this is overkill for your case, I don't recommend it.