La desventaja más inmediata de ejecutar un proceso en tiempo real es que el proceso puede eliminar fácilmente cualquier otro proceso en el sistema. El resultado desde su punto de vista será que la computadora no responde completamente al teclado, al mouse y probablemente a la red, siempre que el proceso en tiempo real utilice la CPU. Esto puede suceder si algo sale mal y el proceso entra en un bucle infinito, o incluso temporalmente si el proceso comienza un cálculo de larga duración sin esperar la entrada periódicamente. (Entonces, por ejemplo, no ejecute SETI @ home con prioridad en tiempo real).
Es menos probable que un proceso de un solo subproceso en una CPU de múltiples núcleos cause este problema, ya que hay otros núcleos que puede utilizar el proceso de menor prioridad. Pero si ese proceso crea procesos secundarios, heredarán la misma prioridad en tiempo real, por lo que las cosas pueden salirse de control si no tiene cuidado.
La sched_setscheduler(2)
página del manual tiene buenos consejos:
Dado que un bucle infinito sin bloqueo en un proceso programado en SCHED_FIFO o SCHED_RR bloqueará todos los procesos con menor prioridad para siempre, un desarrollador de software siempre debe tener disponible en la consola un shell programado con una prioridad estática más alta que la aplicación probada. Esto permitirá una eliminación de emergencia de las aplicaciones probadas en tiempo real que no bloquean ni finalizan como se esperaba. Consulte también la descripción del límite de recursos RLIMIT_RTTIME en getrlimit (2).
Eso debería ser un shell en la consola , no bajo un Xterm, a menos que desee darle también prioridad a X en tiempo real.