how to test the function called by thread?
Debugger is not coming at the point where i kept break point for testing in the function called by the thread using thread start method.
Thanks in advance.
Related
With reference to JVCL TJvThreadTimer.OnTimer : Is This Code Executed in The TJvThreadTimer, ie. NOT the main thread, we know the JVCL threaded timer does its timing part in a thread, but the OnTimer code is executed in the main thread. At least, that's what I understood from that. Please correct me if I'm wrong.
Is there a timer component at hand that does both timing and event in a thread? Under 10msec resolution would be good too. My searching has not found one. Thank you.
I have the same situation like this: stop thread started by qtconcurrent::run
I need to close child thread (started with QtConcurrent::run) on closeEvent in QMainWindow.
But my function in child thread use code from *.dll: I can`t use loop because all that I do - is calling the external dll like
QFuture<void> = QtConcurrent::run(obj->useDllfunc_with_longTermJob());
And when I close the app with x-button my gui is closed, but second thread with_longTermJob() still worked and when is finished I have an error.
I know some decisions for this:
using other functions like map() or something else with
QFuture.cancel/stop functionality, not QtConcurrent::run().But I need only one function call. run() is what I need.
or use QThread instead Concurrent.But it`s not good for me.
What method more simple and better and how can I implement this? Is there a method that I don`t listed?
Could you provide small code sample for decision. Thx!
QtConcurrent::run isn't a problem here. You must have means of stopping the dllFuncWithLongTermJob. If you don't have such means, then the API you're using is broken, and you're out of luck. There's nothing you can do that'd be generally safe. Forcibly terminating a thread can leave the heap in an inconsistent state, etc. - if you need to terminate a thread, you need to immediately abort the application.
Hopefully, you can call something like stopLongTermJob that sets some flag that interrupts the dllFuncWithLongTermJob.
Then:
auto obj = new Worker;
auto objFuture = QtConcurrent::run([=]{obj->dllFuncWithLongTermJob();});
To interrupt:
obj->stopLongTermJob(); // must be thread-safe, sets a flag
objFuture.waitForFinished();
According to the Qt manual on QThread the quit() function waits for the current task to terminate and then ends the event loop.
After having called quit() and wait() for proper termination,
is it legal to start the same instance of the QThread again using start().
The code seems to be working all right but after a restart the Thread ID changes.
There is no mention of this in the docs and all examples seem to create a new Thread instance or don't call quit, so I was wondering.
Yes, it's legal to start a thread again if it was properly stopped.
And this is what the doc says about thread id (emphasis mine):
Qt::HANDLE QThread::currentThreadId()
Returns the thread handle of the currently executing thread.
Warning: The handle returned by this function is used for internal
purposes and should not be used in any application code.
So you should not care about thread id change.
I'm using a Timer and let it perform regular checks. If the test condition is true, I start a thread and let it do what it has to do.
If within that thread I want to change the UI I'm using InvokeOnMainThread(). But as the thread was triggered from a Timer which already is a seprate thread, the InvokeOnMainThread() will invoke things on the Timer's thread and not on the real main thread. I work around it by boxing two InvokeOnMainThread() calls.
Is this working as intended or is it a bug in the Mono framework?
Is the main thread defined as the one who triggered the current thread or is it supposed to return the "root" thread?
NSObject.InvokeOnMainThread is, mostly, a wrapper around performSelectorOnMainThread:withObject:waitUntilDone:
Quote from documentation:
You can use this method to deliver messages to the main thread of your application. The main thread encompasses the application’s main run loop, and is where the NSApplication object receives events.
We can have a deeper look into it (seems weird) if you fill a bug report on http://bugzilla.xamarin.com along with a self-contained test case.
At the moment, I am using WaitForSingleObject to wait for a sub-task thread to complete. Unfortunately, this causes my GUI to lock up. What I would like to do instead, is set a handler (in the GUI thread) that will be called after the sub-task thread is complete. Is there another function for this?
What you can do is to let the last thing that your thread does be posting a custom message to your window. Then handle that as a regular message using MFC's message map. If you cannot change the thread code, you can create a new thread that waits for your thread and then sends the message.
As you already noticed, it is not a good idea to lock up the GUI thread...
Edit: Posting the message is done using the PostMessage function as pointed out by Hans in the comments.
Could also have a look at MsgWaitForMultipleObjects (or MsgWaitForMultipleObjectsEx).
These allow a thread to wait for event handles and service windows messages (examine the return value to see what causes the call to return). Examples of usage should be available via a goodle search.
http://msdn.microsoft.com/en-us/library/ms684245(VS.85).aspx