Обновление работающей программы

Непонятно, твоя прога на чём?

В оригинальном посте есть фраза: язык реализации (ocaml), так что он и используется.

Я бы сделал немного по другому. Надо просто предусмотреть в твоей программе чтобы она имела возможность перед завршением породить дочерний процесс, который бы перезапускал ее :)

Голова-супервайзер (в ней же функционал по поиску новых модулей по какому-нмбудь сигналу), .so и -ldl, даже на таком примитивном уровне реализовать можно.

>Пишу программу у которой критична работа 24 часа в сутки, т.е. всегда

Быстро поднятое не считается упавшим:). Задай себе вопрос "как определяется опущеность программы". Скорее всего ответ будет "по непринятым сессиям/запросам". Следовательно всё, что нужно - это запуск новой версии с передачей ей "обслуживаемых" каналов. А можно и просто перезапустить - если время загрузки сильно меньше среднего интервала между "запросами" и "клиенты" умеют повторять их.

Самый тупой способ - exec("new_copy_of_self"). Открытые файловые дескрипторы наследуются (есле не стоит флаг close-on-exec, но его можно не ставить/убрать). Их номера можно передавать, скажем, в командной строке, типа

execl("/prog/new_copy", "new_copy", "--listen-fileno", itoa(listen_fd), (char *)NULL);

Или, действительно, супервизор+воркеры в *.so

Проблема в том что простой даже в 1 секунду или падение коннекта может стоить слишком много.

а если это не си?

> Проблема в том что простой даже в 1 секунду или падение коннекта может стоить слишком много.

Тогда HA-кластеры - ваше фсё. Если, конечно, "слишком дорого" - это больше, чем $5000.

Ну и, мысль такая, что если это веб-нечто, то "простой в 1 секунду" - фигня. Если не веб - то можно организовать graceful fallback на уровне протокола.

Нет, это дороже, очень много дороже.

Что касаеся кластеров я все это понимаю но вопрос в обновление ноды на лету а не в чем-то еще, ибо процесс переноса коннкета на другую ноду может быть расчитан как "простой в 1 секунду" (пока они будут синхронизироваться) ;)

> Что касаеся кластеров я все это понимаю но вопрос в обновление ноды на лету а не в чем-то еще, ибо процесс переноса коннкета на другую ноду может быть расчитан как "простой в 1 секунду" (пока они будут синхронизироваться) ;)

Эээ. Ну вот представили тупой HA-кластер ака зеркало. Состоит он, очевидно, из SLB-фронтенда (который ничего не делает, кроме как распределяет запросы) и двух (или более) фронтендов, пускай А и Б.

Алгоритм -

for each Node in (А, Б):

отключаем ноду Node от SLB (все новые запросы идут на оставшиеся узлы).

Дожидаемся отработки всех текущих запросов на Node.

Перестартовываем программу.

Подключаем Node обратно к SLB.

end;

Недостаток - какой-то момент времени у вас будет несимметричный кластер, и производительность в момент рестарта снижается на 1/N, где N - количество узлов.

Но зато это куда как проще и надежнее, чем замена кусков кода на лету. А если вам глобальную структуру данных нужно поменять (ну там, было дерево - стало тормозить - перешли на хеш-таблицу)? Будете писать конвертер-на-лету? А если эта структура - обновляемая?

Огребете проблем, имхо, с таким подходом, больше, чем решите.

Это то все понятно, а если коннект длится неделю? Ожидать неделю? И неделю терпеть тормоза на кластере.

Ибо smtp/http протоколы это конечно хорошо, но это 20 век, сейчас учше дизайнить сессионные протоколы, когда человек весь период работы держится на ноде.

Вот из-за этого и пошел геморой с подменой кода...

Что самое интересное, если крутиться в пределах vm то я даже знаю как это делать, приколы начинаются с компилированным кодом (буть-то байт код или оптимизированный)