а если я получил сообщение по сети, и в течение 25 миллисекунд мне надо отправить ответ. когда хоп запускается какой-нибудь haskell garbage collection который невозможно контролировать, и приехали.
Если подойти к вопросу серьёзно, то надо задаться вопросом: насколько жёсткие эти ограничения про 25 миллисекунд. Допустимо ли какое-то превышение дедлайна (например: допустимо для менее чем 0.5% запросов, при этом среднее время < 10 мс).
Так вот, я уверен, что 25 мс — это не жёсткое ограничение (превышения недопустимы). И C++ и отсутствие automatic memory management тут не сильно поможет: есть ещё такие вещи как операционная система, которая может внезапно начать освобождать свои ресурсы и заблокировать I/O надолго, внезапный SMI (http://en.wikipedia.org/wiki/System_Management_Mode), который может остановить всё выполнение на какие-нибудь 100+ миллисекунд (и который by design не отключить), и другие радости.
Так вот, существуют уже схемы сборки мусора которые позволяют предоставить гарантии на максимальную задержку, которую они вносят. Google "incremental real-time garbage collection".
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2010-02-11 06:46 am (UTC)Так вот, я уверен, что 25 мс — это не жёсткое ограничение (превышения недопустимы). И C++ и отсутствие automatic memory management тут не сильно поможет: есть ещё такие вещи как операционная система, которая может внезапно начать освобождать свои ресурсы и заблокировать I/O надолго, внезапный SMI (http://en.wikipedia.org/wiki/System_Management_Mode), который может остановить всё выполнение на какие-нибудь 100+ миллисекунд (и который by design не отключить), и другие радости.
Так вот, существуют уже схемы сборки мусора которые позволяют предоставить гарантии на максимальную задержку, которую они вносят. Google "incremental real-time garbage collection".