pynta.tools package¶
Submodules¶
pynta.tools.worker_thread module¶
work_thread.py¶
Running the acquisition on a separate thread gives a lot of flexibility when designing the program. It comes, however with some potential risks. First, threads are still running on the same Python interpreter. Therefore they do not overcome the GIL limitations. They are able to share memory, which makes them transparent to less experienced users. Potentially, different threads will access the same resources (i.e. devices) creating a clash. It is hard to implement semaphores or locks for every possible scenario, especially with devices such as cameras which can run without user intervention for long periods of time.
- copyright
Aquiles Carattino <aquiles@uetke.com>
- license
AGPLv3, see LICENSE for more details
-
class
pynta.tools.worker_thread.WorkerThread(camera, keep_alive=False)[source]¶ Bases:
threading.ThreadThread for acquiring from the camera. If the exposure time is long, running on a separate thread will enable to perform other tasks. It also allows to acquire continuously without freezing the rest of the program.
Todo
QThreads are much handier than Python threads. Should we put Qt as a requirement regardless of whether the program runs on CLI or UI mode?
-
run()[source]¶ Method representing the thread’s activity.
You may override this method in a subclass. The standard run() method invokes the callable object passed to the object’s constructor as the target argument, if any, with sequential and keyword arguments taken from the args and kwargs arguments, respectively.
-