Что такое Hard Real-Time?

Давай разберём, что за зверь такой — Hard Real-Time, чтобы потом не орать «ёпта, а почему всё накрылось медным тазом?».

Представь, что у тебя есть задача. Не просто «надо бы», а такая, что если ты её не сделаешь точно в срок — будет пиздец. Не «ой, опоздал на пять минут», а «всё, пиши пропало, оборудование в хлам, люди пострадали». Вот это и есть системы жёсткого реального времени. Пропустил дедлайн — всё, это уже не «баг», это полный, окончательный, ебальный отказ. Доверия ебать ноль к системе, которая опоздала.

Что от них хотят, эти системы?

• Предсказуемость, ёпта! Не «в среднем быстро», а «гарантированно за N миллисекунд, и точка». Это называется детерминированность. Ты должен знать наверняка, сколько времени займёт операция, даже в худшем случае.
• Своевременность важнее всего. Можно выдать чуть менее точный результат, но ВОВРЕМЯ. А можно выдать идеальный результат, но с опозданием — и это будет полная хуйня, потому что поезд уже ушёл, самолёт уже в землю врезался, а пациент уже откинулся.
• Время — главный приоритет. Не «обработаем побольше данных», а «обработаем ровно столько, сколько успеем за свой строгий временной интервал».

Где это, блядь, применяется? Примеры, чтобы не быть голословным:

1. Самолёты. Автопилот получает данные, что самолёт заваливается на крыло. У него есть, условно, 10 миллисекунд, чтобы дать команду элеронам выровняться. Если он подумает 15 — ядерёна вошь, вы все уже падаете камнем вниз.
2. Дефибриллятор. Ему нужно бить током в очень конкретную, короткую фазу сердечного ритма. Попал в момент — сердце запустил. Опоздал или поторопился — ебушки-воробушки, можно только навредить.
3. Автоматический тормоз на заводском прессе. Рука человека попала в опасную зону — сигнал с датчика должен долететь до контроллера, и тот должен дать команду «стоп» быстрее, чем челюсть пресса сомкнётся. Промедление — хуй в пальто, у тебя теперь инвалид на производстве.

А теперь главный вопрос: почему на Node.js такое не сделаешь? Вот сидишь ты, такой умный, и думаешь: «А, event loop, асинхронщина, быстро же!». Ага, щас. Подозрение ебать чувствую, что ты не всё учитываешь.

• Event Loop — не панацея. Запустил ты там какую-нибудь тяжелую синхронную операцию (типа шифрования или парсинга огромного JSON) — и всё, цикл встал колом. Все остальные задачи, включая твою критическую, ждут, пока этот долгий синхронный кусок не отработает. Волнение ебать — когда он освободится, никто не гарантирует.
• Сборка мусора (Garbage Collector). Это вообще хитрая жопа. Она может прийти в самый неподходящий момент и сказать: «Стоять! Я тут почищу память!». И всё замирает на неопределённое время. А в Hard Real-Time терпения ноль ебать — система должна отвечать всегда.
• Обычная операционка (Windows, Linux). Она не для этого. У неё там свои дела: планировщик задач переключает процессы, какие-то прерывания срабатывают, диск туда-сюда данные гоняет. Твоя высокоприоритетная задача может внезапно оказаться в очереди из-за какой-нибудь системной фигни. Удивление пиздец — а дедлайн уже пролетел.

Так на чём тогда это всё делают? Для такого пиздопроебибна нужны специальные инструменты:

• Специальные ОС реального времени (RTOS): QNX, VxWorks, FreeRTOS. Они устроены так, чтобы гарантировать время отклика. Там планировщик другой, прерывания обрабатываются иначе.
• Языки, близкие к железу: C, C++, Ada, Rust (в no_std режиме, без всей своей стандартной библиотеки, которая может быть недетерминированной). Тут ты контролируешь каждый такт процессора и каждую байтовку памяти. Никаких сюрпризов.

Короче, если тебе нужна система, где опоздание = катастрофа, забудь про Node.js, Python и прочую высокоуровневую братию. Это территория суровых бородатых инженеров, которые пишут на Си и знают, что такое хуй с винтом от непредсказуемого поведения. Тут нужна абсолютная гарантия, а не «ну, в 99.9% случаев работает быстро».