Function apply_to_current_thread 

pub fn apply_to_current_thread(priority: ThreadPriority) -> PriorityApplied

Apply an EPICS ThreadPriority to the current OS thread, best effort.

C parity: mirrors osdThread.c’s SCHED_FIFO mapping oss = p * (max-min)/100 + min over the kernel’s sched_get_priority_min/max(SCHED_FIFO) range, and the EPERM-fallback to a non-RT thread.

Returns PriorityApplied describing what the platform allowed — callers running in environments without RT permission still get a running thread, just at the default policy, exactly as a C IOC does.

Note: tokio tasks spawned via spawn share worker threads, so this is meaningful for spawn_blocking closures and for tuning the runtime’s worker threads at startup — not for individual async tasks.

Platform support: the OS-scheduler change is wired on Linux, via the range-probed linear map of os/posix/osdThread.c, and on RTEMS, via the fixed map of os/RTEMS-score/osdThread.c inverted into POSIX space (see map_epics_priority_rtems — the two maps differ in shape, deliberately). On other targets the priority enum + API surface still exist but apply reports PriorityApplied::Unsupported — no band has been measured there.

Opt-in: real-time scheduling is only ever requested when RT_PRIORITY_ENV is set (see RtPolicy). With the switch off this returns PriorityApplied::Disabled without calling the OS at all.