In this implementation, the internal state of a Python library is simply cleared, regardless of whether the ThreadPoolExecutors are being used by other programs. This is not good because in newer Python versions (> 3.8), ThreadPoolExecutor threads are no longer Daemon Threads, and when Python is being terminated, it waits for the ThreadPoolExecutors/Queues to be terminated as well.
Deleting the Python internal concurrent.futures.threads._threads_queues is actually unnecessary since Python takes care of terminating the threads. If the intention is to terminate only the threads started by the run_in_background decorator, then only those threads should be terminated and not all the threads in the system.
What is the reason for deleting the _threads_queues?
For RobotCode, I encountered this bug where the RobotCode Debugger does not terminate when recording videos.
After some research, I found out that this error is due to an incorrect implementation of the clear_thread_queues method in the Client class.
https://github.com/rticau/ScreenCapLibrary/blob/146304edac5a062a39f6c738a0516212acbd0197/src/ScreenCapLibrary/client.py#LL252C22-L252C22
In this implementation, the internal state of a Python library is simply cleared, regardless of whether the ThreadPoolExecutors are being used by other programs. This is not good because in newer Python versions (> 3.8), ThreadPoolExecutor threads are no longer Daemon Threads, and when Python is being terminated, it waits for the ThreadPoolExecutors/Queues to be terminated as well.
Deleting the Python internal concurrent.futures.threads._threads_queues is actually unnecessary since Python takes care of terminating the threads. If the intention is to terminate only the threads started by the run_in_background decorator, then only those threads should be terminated and not all the threads in the system.
What is the reason for deleting the _threads_queues?