Function enter_ioc_thread 

pub fn enter_ioc_thread(priority: ThreadPriority) -> PriorityApplied

The prologue an IOC thread runs as its first statement, when it takes on its role: publish its name to the OS, then request its scheduling band.

Two things a thread owes the operator, and they have different gates. The band is opt-in (RT_PRIORITY_ENV) and best effort. The name is unconditional: a thread that cannot be identified in a task listing cannot be diagnosed, and on RTEMS that listing is often the only instrument there is — bring-up had to measure libbsd’s priority band by other means precisely because none of our threads carried a name the kernel could show.

Use this rather than apply_to_current_thread at a thread’s entry, so naming cannot be forgotten by the next thread somebody adds. Call apply_to_current_thread directly only when re-banding a thread that is already named and running. A thread that deliberately takes no EPICS band — the iocsh script runners — calls name_current_thread alone rather than inventing a priority just to be visible.

The band this asks the OS for is also what orders the blocking locks in server::database::record_lock and its siblings: they are priority-inheritance mutexes, so the wait queue is the kernel’s and it is ranked by the scheduling priority requested here. With RtPolicy::Disabled no scheduler call happens and there is no ordering to have — the hosted default, where the locks still exclude but do not prioritise (crate::runtime::sync::is_pi_mutex_active). A third thing on VxWorks, for the same reason as the name: an RTP cannot enumerate its own tasks, so the statistics funnel’s thread census is built from what announces itself here. This is the seam because it is already the one every IOC thread passes through to take its band — “every thread that bands itself registers itself” adds a consequence to that invariant rather than a rule to remember at each spawn. A thread that starts outside it is invisible to that census, and the census output says so in its own header.