Hi, thanks for maintaining this crate.
When the crate is built without the dbus feature, promote_current_thread_to_real_time on Linux falls through to the blanket fallback branch in src/lib.rs (the "Android, Linux Desktop without dbus and others" arm) and is a no-op that returns Ok without changing the thread's scheduling. So a no-D-Bus build silently does nothing on Linux, and because it still returns Ok, callers believe promotion succeeded.
I'd like to make that fallback actually promote the current thread, using pthread_setschedparam(self, SCHED_FIFO | SCHED_RESET_ON_FORK, ...), with pthread_getschedparam saving the prior policy/params so demotion can restore them. This is the mechanism JACK and PipeWire's direct mode use. It works wherever the process is allowed to request real-time scheduling (running as root, CAP_SYS_NICE, or an RLIMIT_RTPRIO limit), and needs no libdbus and no rtkit daemon, which suits minimal/headless and privileged deployments where rtkit isn't present or wanted.
I saw in #1 that rtkit was chosen because Firefox runs unprivileged and sandboxed and can't call the scheduling syscalls directly. This proposal keeps rtkit as the default (dbus) path untouched; it only gives the currently-useless no-dbus fallback real behavior (which #8 suggests is meant to stay buildable anyway). On a missing-permission EPERM it would return Err, so existing callers keep their warn-and-continue behavior.
Two things I'd like to sort out before sending a PR:
- Shape. Would you prefer the no-
dbus Linux build to promote directly as described, or the native path gated behind a separate feature? I lean towards the former since it only fixes an existing no-op and adds no new surface.
RLIMIT_RTTIME. The rtkit path sets it because rtkit requires it. The direct path doesn't strictly need it (the kernel's real-time throttling already guards against a runaway thread), and setting it risks SIGXCPU if budgeted too tightly. Leave it unset, or set it as a safeguard?
Happy to open the PR once the direction is clear.
Hi, thanks for maintaining this crate.
When the crate is built without the
dbusfeature,promote_current_thread_to_real_timeon Linux falls through to the blanket fallback branch insrc/lib.rs(the "Android, Linux Desktop without dbus and others" arm) and is a no-op that returnsOkwithout changing the thread's scheduling. So a no-D-Bus build silently does nothing on Linux, and because it still returnsOk, callers believe promotion succeeded.I'd like to make that fallback actually promote the current thread, using
pthread_setschedparam(self, SCHED_FIFO | SCHED_RESET_ON_FORK, ...), withpthread_getschedparamsaving the prior policy/params so demotion can restore them. This is the mechanism JACK and PipeWire's direct mode use. It works wherever the process is allowed to request real-time scheduling (running as root,CAP_SYS_NICE, or anRLIMIT_RTPRIOlimit), and needs no libdbus and no rtkit daemon, which suits minimal/headless and privileged deployments where rtkit isn't present or wanted.I saw in #1 that rtkit was chosen because Firefox runs unprivileged and sandboxed and can't call the scheduling syscalls directly. This proposal keeps rtkit as the default (dbus) path untouched; it only gives the currently-useless no-dbus fallback real behavior (which #8 suggests is meant to stay buildable anyway). On a missing-permission
EPERMit would returnErr, so existing callers keep their warn-and-continue behavior.Two things I'd like to sort out before sending a PR:
dbusLinux build to promote directly as described, or the native path gated behind a separate feature? I lean towards the former since it only fixes an existing no-op and adds no new surface.RLIMIT_RTTIME. The rtkit path sets it because rtkit requires it. The direct path doesn't strictly need it (the kernel's real-time throttling already guards against a runaway thread), and setting it risksSIGXCPUif budgeted too tightly. Leave it unset, or set it as a safeguard?Happy to open the PR once the direction is clear.