You know that you must contaminate your code and long computation with "isCancelled" polling. This is called a "graceful termination". On the other hand, you cannot simply kill a thread. It may have acquired some lock and in the process of modifying some global data. If you terminate it abruptly, your system state stays corrupted. I propose to kill the threads from a mutually exclusive section.
When worker completes computation, it normally enters a mutex and reports the result. This means that to kill that thread, you need to take the same mutex. This prevents global state corruption. The state of the thread is useless (GC will care about it, unless we talk about persistent temporary files (they are temporary but do not disappear with thread and, thus, are persistent) and threads/jobs/processes, spawned by the worker). This may not work for unmanaged environments. How can we GC the spawned objects? Might be we can interrupt the thread by exception? Then, it will close all its resources automatically, by try-finally.
When worker completes computation, it normally enters a mutex and reports the result. This means that to kill that thread, you need to take the same mutex. This prevents global state corruption. The state of the thread is useless (GC will care about it, unless we talk about persistent temporary files (they are temporary but do not disappear with thread and, thus, are persistent) and threads/jobs/processes, spawned by the worker). This may not work for unmanaged environments. How can we GC the spawned objects? Might be we can interrupt the thread by exception? Then, it will close all its resources automatically, by try-finally.
No comments:
Post a Comment