:orphan:

.. title:: CONFIG_NUM_METAIRQ_PRIORITIES

.. kconfig:: CONFIG_NUM_METAIRQ_PRIORITIES

CONFIG_NUM_METAIRQ_PRIORITIES
#############################

*Number of very-high priority 'preemptor' threads*

Type: ``int``

Help
====

.. code-block:: none

    This defines a set of priorities at the (numerically) lowest
    end of the range which have "meta-irq" behavior.  Runnable
    threads at these priorities will always be scheduled before
    threads at lower priorities, EVEN IF those threads are
    otherwise cooperative and/or have taken a scheduler lock.
    Making such a thread runnable in any way thus has the effect
    of "interrupting" the current task and running the meta-irq
    thread synchronously, like an exception or system call.  The
    intent is to use these priorities to implement "interrupt
    bottom half" or "tasklet" behavior, allowing driver
    subsystems to return from interrupt context but be guaranteed
    that user code will not be executed (on the current CPU)
    until the remaining work is finished.  As this breaks the
    "promise" of non-preemptibility granted by the current API
    for cooperative threads, this tool probably shouldn't be used
    from application code.

Default
=======

- 0

Kconfig definition
==================



At ``<Zephyr Kernel>/Kconfig:91``

Included via ``Kconfig:8`` → ``Kconfig.zephyr:40``

Menu path: (Top) → General Kernel Options

.. code-block:: kconfig

    config NUM_METAIRQ_PRIORITIES
    	int "Number of very-high priority 'preemptor' threads"
    	default 0
    	help
    	  This defines a set of priorities at the (numerically) lowest
    	  end of the range which have "meta-irq" behavior.  Runnable
    	  threads at these priorities will always be scheduled before
    	  threads at lower priorities, EVEN IF those threads are
    	  otherwise cooperative and/or have taken a scheduler lock.
    	  Making such a thread runnable in any way thus has the effect
    	  of "interrupting" the current task and running the meta-irq
    	  thread synchronously, like an exception or system call.  The
    	  intent is to use these priorities to implement "interrupt
    	  bottom half" or "tasklet" behavior, allowing driver
    	  subsystems to return from interrupt context but be guaranteed
    	  that user code will not be executed (on the current CPU)
    	  until the remaining work is finished.  As this breaks the
    	  "promise" of non-preemptibility granted by the current API
    	  for cooperative threads, this tool probably shouldn't be used
    	  from application code.

*(The 'depends on' condition includes propagated dependencies from ifs and menus.)*