Background threads in KTL Python
======================================

.. currentmodule:: ktl

The earliest use of threads in KTL Python was to invoke :func:`ktl_dispatch`
whenever a file descriptor indicated that KTL events were waiting to be
processed. While there is still a :class:`thread object <Dispatcher>` dedicated
to this task (now on a per-:class:`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
:func:`heartbeat keyword <Service.heartbeat>` is still active.

All background threads in KTL Python are started automatically. Frequently
used threads, such as the :class:`Usher`, start when the :mod:`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 :class:`FirstResponder` and :class:`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.


Essential threads
-----------------

.. autoclass:: Usher.Usher ()
.. autoclass:: Service.Janitor ()
.. autoclass:: log.Lumberjack ()


On-demand threads
-----------------

.. autoclass:: Service.Dispatcher
.. autoclass:: Service.FirstResponder
.. autoclass:: Service.Paramedic
   :members: resuscitate


Parent thread class
-------------------

.. autoclass:: Thread.Typical
   :members: