start and programmatically stop a thread
-
ok thank you very much.
Terminate(); the function within the thread does not used shared resources, and does not read/write to/from disk
Have a nice day
G@gbettega
That is what I meant byYou might "kill" it forcefully, but almost certainly that will leave things in a bad state.
As per docs:
Warning: This function is dangerous and its use is discouraged. The thread can be terminated at any point in its code path. Threads can be terminated while modifying data. There is no chance for the thread to clean up after itself, unlock any held mutexes, etc. In short, use this function only if absolutely necessary.
Use at your own risk!
-
@gbettega
That is what I meant byYou might "kill" it forcefully, but almost certainly that will leave things in a bad state.
As per docs:
Warning: This function is dangerous and its use is discouraged. The thread can be terminated at any point in its code path. Threads can be terminated while modifying data. There is no chance for the thread to clean up after itself, unlock any held mutexes, etc. In short, use this function only if absolutely necessary.
Use at your own risk!
-
@gbettega said in start and programmatically stop a thread:
What does exactly "bad state" means?
UB (undefined behavior), for example...
If you stop/terminate the thread while processing it might leave garbage values behind, which then cause errors elsewhere.
You can never be sure that everything is working as it should after "killing" the thread forcefully.
terminate()IS a solution, but not a good one.All depends on what your thread/your app is doing.
@gbettega said in start and programmatically stop a thread:
the thread does not used shared resources, and does not read/write to/from disk
It could potentially work for you... but could also result in errors later.
-
@gbettega
All as @Pl45m4 has written. It means "It works OK, if you're lucky, till some time it does not, if you are unlucky".Depending on what happens to happen when, you can kill it lots of times with no ill effects, then perchance one time it gets killed at a different state and that does have an effect. It does help mitigation that your thread at least "does not access anything else", but there are other things which can be affected.
What is it that this DLL code does which takes so long to compute and does not allow for interruption/termination? Would you consider, maybe, that when user asks for "stop" you allow the thread to run to normal termination but disconnect/ignore any signals or output it sends you? That might be safer than killing.
-
@gbettega
All as @Pl45m4 has written. It means "It works OK, if you're lucky, till some time it does not, if you are unlucky".Depending on what happens to happen when, you can kill it lots of times with no ill effects, then perchance one time it gets killed at a different state and that does have an effect. It does help mitigation that your thread at least "does not access anything else", but there are other things which can be affected.
What is it that this DLL code does which takes so long to compute and does not allow for interruption/termination? Would you consider, maybe, that when user asks for "stop" you allow the thread to run to normal termination but disconnect/ignore any signals or output it sends you? That might be safer than killing.
@JonB thank you for your reply.
The code sent to the thread performs a geometry/topology operation performed on a BREP file. E.g. a defeatuting operation done on a complex shape geometry. It is one among the typical operations a geometry kernel of a CAD software performs onto n input geometry. If the required simplification is "simple" the dll takes a fraction of second, or less, but, if the defeaturing operation is made of multiple simplifications onto a complex shape, or multiple shapes, the kernel (here OpenCascade) could take serveral minutes, and in the meantime the GUI should remain unlocked. There is also the possibility that the code inside the library gets stuck: the user cannot distinguish between a stuck state (infinite loop) or a very long operation, so he generally "quits". Ignoring all it is happening in this case is not feasible, since these operations when running are intensive, both in terms of memory, both in terms of CPU.
Have a nice day
GIovanni -
@JonB thank you for your reply.
The code sent to the thread performs a geometry/topology operation performed on a BREP file. E.g. a defeatuting operation done on a complex shape geometry. It is one among the typical operations a geometry kernel of a CAD software performs onto n input geometry. If the required simplification is "simple" the dll takes a fraction of second, or less, but, if the defeaturing operation is made of multiple simplifications onto a complex shape, or multiple shapes, the kernel (here OpenCascade) could take serveral minutes, and in the meantime the GUI should remain unlocked. There is also the possibility that the code inside the library gets stuck: the user cannot distinguish between a stuck state (infinite loop) or a very long operation, so he generally "quits". Ignoring all it is happening in this case is not feasible, since these operations when running are intensive, both in terms of memory, both in terms of CPU.
Have a nice day
GIovanni -
A safer option is to run the calculation in a separate process. Termination there is easier to understand for a seasoned programmer.
-
Stdin and stdout of the child process work for low volumes. Shared memory for large data sets. It's unusual to want a multithreaded algorithm and not understand some form of IPC.
The risk of having a memory allocation abandoned, or a library dependency leaving a mutex locked dissuades me from considering QThread::terminate() in any circumstance.
-
Like previously stated, the only real option you have is to start a separate process from your Qt application. This process loads the DLL and performs the calculations.
You can then terminate that process at any time, and the operating system will take care of cleaning up memory, handles, and other resources. The only potential downside is the risk of corrupted files, if the DLL performs file operations.
Communication between your main application and the second process can be handled via QSharedMemory, QLocalSocket, or standard input/output piping.
