workload-automation/doc/source/instrument_method_map.template

.. _instruments_method_map:

Instrumentation Signal-Method Mapping
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Instrument methods get automatically hooked up to signals based on their names.
Mostly, the method name corresponds to the name of the signal, however there are
a few convenience aliases defined (listed first) to make  easier to relate
instrumentation code to the workload execution model. For an overview on when
these signals are dispatched during execution please see the
:ref:`Developer Reference <signal_dispatch>`.

$signal_names

The methods above may be decorated with on the listed decorators to set the
priority of the Instrument method relative to other callbacks registered for the
signal (within the same priority level, callbacks are invoked in the order they
were registered). The table below shows the mapping of the decorator to the
corresponding priority:

$priority_prefixes


Unresponsive Targets
~~~~~~~~~~~~~~~~~~~~

If a target is believed to be unresponsive, instrument callbacks will be
disabled to prevent a cascade of errors and potential corruptions of state, as
it is generally assumed that instrument callbacks will want to do something with
the target.

If your callback only does something with the host, and does not require an
active target connection, you can decorate it with ``@hostside`` decorator to
ensure it gets invoked even if the target becomes unresponsive.