I have a utility which will access the database and clean the garbage files. this is a console application which is being called from another application.
I have a thread from the main thread which will do the tasks while the main thread will be in a loop to check if cancel of the utility has been called.
The functions in the thread call a different dll which takes time. Now, is there any way that when I cancel the thread. Even if it is inside the function, it gets notified to stop immediately and rollback any changes done to the database?
My application is a windows based application and is written in c++. I have tried using TerminateThread() function from Windows but the problem is that is does not allow to do clean up on the thread.
Related
So the problem is that in any application sometimes the GUI might freeze. Regardless of why it has happened, I want to be able to terminate/exit/quit my application.
Is there any way to do it from another thread (in the same application instance)? Assume that the GUI event loop is frozen and stuck in a while(1); line for example!
What I've already tried:
Calling QCoreApplication::quit() on qApp from another thread, which doesn't work because the GUI event loop is blocked.
Calling QCoreApplication::exit() on qApp from another thread, which doesn't work because it says I can only call it from the GUI thread.
If it is not possible to do it from another thread, how would you suggest to exit the application, assuming the GUI thread is blocked?
Do you want a hard or a graceful exit? For a super hard exit, that can't be blocked by shutdown handlers (destructors, functions registered with atexit) use the C standard function abort: https://en.cppreference.com/w/cpp/utility/program/abort
It’s customary to use a separate watchdog application for that instead. It should regularly ping your application, and if that fails, kill it and restart it. Doing it from within the application itself doesn’t sound very reliable.
Back to stackoverflow with another question after hours of trying on my own haha.
Thank you all for reading this and helping in advance.
Please note the console program has following functionalities:
connect to a frame grabber
apply some configs
store the incoming data (640 * 480 16-bit grayscale imgs) in a stream of buffers inside a while loop
Exits the while loop upon a key press.
disconnect from device
And I'm only adding the displaying the images functionality on the MFC GUI app. In short,
i) Converting a console app to an MFC app (dialog based)
ii) decided to use thread for displaying images, but DK how to properly exit from thread when there are certain tasks to be done (such as call disconnectFromDevice(); freeBuffers();, etc) before exiting the thread.
iii) have tried making the while loop condition false but didn't work
( I actually want this to be a callback function that's called repeatedly but IDK how to implement it inside a thread)
iv) forcing AfxEndThread didn't work and it's not even the way it should be done (I think).
So my question is,
1. Are you supposed to use a while loop to excuete a certain job that should repeatedly be done? If not, do you have to implement a callback inside a thread? Or use Windows message loop? Why and how? Please provide a hello-world-like sample code example
(for example, you are printing "hello world" repeatedly inside a thread with a condtion in an MFC GUI app. How do you update or check the condition to end the thread if you can't just AfxEndThread() inside the threadproc)
2. If it's ok with a while, how do you exit from the while loop, in other words how do you properly update the exit condition outside the thread the while loop's in?
Please refer to the source code in the provided link
ctrl+F OnBnClickedConnectButton, AcquireImages and OnBnClickedDisconnectButton
https://github.com/MetaCortex728/img_processing/blob/main/IR140Dlg.cpp
Worker threads do not have message-queues, the (typically one and only) UI one does. The message-queue for a thread is created by the first call of the GetMessage() function. Why use messages to control processing in a worker thread? You would have to establish a special protocol for this, defining custom messages and posting them to the queue.
Worker threads can be implemented as a loop. The loop can be terminated based on various conditions, like failures to retrieve any data or request from the user. You can simply exit the thread proc to terminate the thread's execution. If the thread doesn't respond it may have stuck (unless it performs a really lengthy operation) and the UI thread must provide some mechanism to kill it. That is first request termination and if it doesn't respond within some set time then kill it.
The condition mechanism to terminate should best be some synchronization object (I would recommend a manual-reset event), interlocked variable or a simple boolean which you should access and set using a critical section.
Some considerations:
You pass a parameter block to the thread. Make sure that it remains alive throughout the thread's lifetime. For example, it should NOT be a local variable in a function that exits before the thread's termination.
The loop must be "efficient", ie do not loop infinitely if data are not available. Consider using blocking functions with timeouts, if available.
Resource management (eg connecting/disconnecting, allocating/releasing etc) should best be performed by the same thread.
An alternative implementation can be APCs. Then the thread's proc function is a while(!bTerminate) { SleepEx(INFINITE, TRUE); } loop, and other threads issue requests using a the QueueUserAPC() function.
The AfxEndThread(0) call in OnBnClickedDisconnectButton() is wrong, it terminates the current thread, which in this case is the main (UI) thread. Check the documentation.
A sidenote, my suggestion about the project type is not a dialog-based application but instead a normal MFC application without a document class (uncheck the Document/View architecture support option), as it offers features like menus, toolbars and the like, and most importantly the ON_UPDATE_COMMAND_UI handlers.
In my MDI application I use the Qt undo/redo framework and it works very well.
Now I have implemented an operation that requires a lot of time, so I would like to run it in another thread so that the application is not freezed and the user can work on the other MDI windows meanwhile.
So I have to run the operation in a new thread inside the redo() method of my QUndoCommand. This is a problem, because:
If I wait inside the redo() method that the thread has finished, the application freezes, so it is useless.
If I don't wait that thread has finished, the redo() method returns before the operation is completed, and this can cause a lot of problems and errors (e.g. if the user uses the undo/redo mechanism, it is possible that the commands following the thread command are executed before it is completed).
Any idea?
You have much bigger problems than undo/redo. Change the architecture so that system behavior is sane when asynchronous data processing is underway. The data manager object should indicate when it's busy, and the UI should reflect that. Once you get this working properly, undo/redo will magically work as well.
I'm on some c++ mobile product, but I need my apps main thread is still running without any blocking when doing some heavy work on the background thread and run back on main thread. But I realized there is no runOnMainThread/runOnUIThread in c++ thread api. I trying to figure it out the issue and found that need to depend library, or create your own thread event queue. Although it is good, but i am thinking to have a behavior which can runOnUIThread.
How it does not work: the mentioned library creates a timer, installs a SIGALRM signal handler and dispatches queued tasks when signals are fired. This allows tasks being processed on the main thread even when it is busy. However POSIX permits only a small set of async-signal-safe functions to be invoked inside of signal handler. Running arbitrary с++ code inside of signal handler violates that restriction and leaves application in hopelessly doomed state.
After some research and development, I've created a library called NonBlockpp
it is a small c++ library to allow c++ mobile application able to process the heavy and time consuming task on background and back to Main thread again, It’s been tested and fired the main thread event.
It also allow to save the tasks and fire them later, all the task has no blocking each other and thread safety.
How it works:
If you found any query or suggestion, please don't hesitate to raise an issue and we can discuss it together.
The project has rectify from signal to pollEvent due to signal handler might not be safe to use.
Please take a look the new changed.
NonBlockpp
Usage
I have a multi-threaded embedded architecture that contains 6 application specific processes which are executed when the initialization process is executed. Likewise, each have their own number of threads that are running.
What i want to do is suspend the running threads of 1 particular process based on whether the device is connected to the pc or not.
I have tried searching around and the closest i've found to what im looking for is the following: How to obtain list of thread handles from a win32 process?
However, that code returns the list of all running threads. This wont work for me since im trying to suspend all obtained threads, assuming they have been obtained from the same process, thus i do not check which process they belong too.
Likewise, i am obtaining the list of running threads of a processes in another process.
Is there an existing method from windows that allows such control, or am i stuck with having to identify which threads i need to suspend from the entire list?
Instead of trying to forcefully suspend threads (which is likely to bring you trouble when you suspend in "not so lucky moment") you'd rather use a named CreateEvent() with manual reset.
Named events are easily shared between processes. You simply CreateEvent() again with the same name. The typical name for event would be MyCompany_MyProduct_MyFeature_EventName to prevent accidental collisions.
When you WaitForSingleObject() on "set" event, the wait is immediately satisfied.
When you wait on "reset" event, the wait suspends your thread until event is set.
Your first application will have its thread(s) wait on event when they're not doing any work and therefore safe to suspend.
You will set and reset event from second application to control the first application.
This way, you don't need to enumerate threads, and it's more robust.