Background threads in KTL Python¶
The earliest use of threads in KTL Python was to invoke ktl_dispatch()
whenever a file descriptor indicated that KTL events were waiting to be
processed. While there is still a thread object dedicated
to this task (now on a per-Service basis), the family of background
threads grew over time. Most of the new threads exist in order to process
common operations that will block while processing, such as writing log data;
a few exist in order to handle timed checks, such as determining whether a
heartbeat keyword is still active.
All background threads in KTL Python are started automatically. Frequently
used threads, such as the Usher, start when the ktl module
is first loaded; this is done in order to prevent frequent checks to see
whether a given thread is running before proceeding with code that requires
it. Others, such as the FirstResponder and Paramedic, are
only started on demand, and are called so infrequently that any extra checks
are not a significant use of processing time.
All thread objects are resilient against failure; barring an unknown bug, there should be no circumstances where they die unexpectedly, or otherwise stop running in the absence of a complete interpreter shutdown.