nanomsg, zeromq и ассерты
Продолжаю вникать в легковесные MQ библиотеки и ужасаюсь одной всепроникающей идее - ассерты в релизном коде, буквально на каждый возможный косяк.
С одной стороны, fail-fast это правильный подход, пусть супервизор процессов разбирается что дальше делать.
С другой - abort или RaiseException на виндах кидают messagebox, а messagebox в виндосервисе, если нет чек-бокса "разрешить взаимодействие с десктопом", это гамон, такой процесс можно только убить, он больше не подчиняется указаниям от сервис-контроллера. То же самое - запуск процессов из task scheduler, этот мессаджбокс будет "где-то висеть" в гребенях сессии в которой запущены сервисы.
Далее, нормальная методика при обработке ошибок: try {} catch(exception) { log(сообщение, параметры вызова, exception);throw}. Т.е. я по крайней мере, по логам узнаю, что привело к исключению (за исключением совсем плохих вещей, типа полной нехватки памяти, умершего железа или выдернутого езернет-провода).
В случае же assert - у меня процесс сдыхает (и не дай бог в соседних потоках писать на диск или работать с железом), причем если супервизор, который может прочесть stderr и скопировать сообщение в свой лок,отсутствует - сообщение об ошибке уйдет в никуда.
Судя по тому, как друг на друга псят Martin Sustrik и Pieter Hintjens, отзывам про либы и тому бардаку, который творится в коде nanomsg(например, комментарий вида: /* For some reason simple CancelIo doesn't seem to work here. We have to use CancelIoEx instead. */ в коде, из-за которого nanomsg вообще не запускается на 2003 и xp), ситуация с этими либами откровенно нехорошая.
С одной стороны, fail-fast это правильный подход, пусть супервизор процессов разбирается что дальше делать.
С другой - abort или RaiseException на виндах кидают messagebox, а messagebox в виндосервисе, если нет чек-бокса "разрешить взаимодействие с десктопом", это гамон, такой процесс можно только убить, он больше не подчиняется указаниям от сервис-контроллера. То же самое - запуск процессов из task scheduler, этот мессаджбокс будет "где-то висеть" в гребенях сессии в которой запущены сервисы.
Далее, нормальная методика при обработке ошибок: try {} catch(exception) { log(сообщение, параметры вызова, exception);throw}. Т.е. я по крайней мере, по логам узнаю, что привело к исключению (за исключением совсем плохих вещей, типа полной нехватки памяти, умершего железа или выдернутого езернет-провода).
В случае же assert - у меня процесс сдыхает (и не дай бог в соседних потоках писать на диск или работать с железом), причем если супервизор, который может прочесть stderr и скопировать сообщение в свой лок,отсутствует - сообщение об ошибке уйдет в никуда.
Судя по тому, как друг на друга псят Martin Sustrik и Pieter Hintjens, отзывам про либы и тому бардаку, который творится в коде nanomsg(например, комментарий вида: /* For some reason simple CancelIo doesn't seem to work here. We have to use CancelIoEx instead. */ в коде, из-за которого nanomsg вообще не запускается на 2003 и xp), ситуация с этими либами откровенно нехорошая.
no subject
no subject
no subject
no subject
no subject
Звучит заманчиво :)
no subject
Возьми кролика. Или редис (хотя там и симулятор очередей ;))
Или возьми ezmq (или как его там -- который с нуля по спекам на ерланге написан) если тебе надо с 0mq именно разговаривать.
no subject
no subject
Тогда try-catch на уровне главной функции должен по идее отлавливать все, что не обрабатывается в приложении.
no subject
no subject
Вообще у мессаджбокса есть флажок MB_SERVICE_NOTIFICATION, но и с ним не всё гладко. Как и с функцией MessageBoxTimeout.
Сама идея взаимодействия с пользователем из процесса, с пользователем не связанного, без желания на то пользователя - бред и зло. Как следствие - не надо бросаться ассёртами из библиотек в релизе.
no subject
no subject
no subject
no subject
Это виндопроблемы, в цивилизованных осях abort() оставляет корку, где как раз и видно что произошло. А в винде вроде нельзя.
no subject
Если архитектура - говно, надо просто это признать и исправить, а не придумывать гнилые отмазки. Окошки с сообщениями имеют смысл только если их есть кому смотреть (a.k.a. интерактивный режим). За сервисом смотреть некому, за ним должен следить запускатор сервисов и писать в логи/слать письма-смс/звонить админу, если сервису стало плохо.
no subject
Но что касается assert - тут уже разработчики библиотеки упускают из виду, что он может разворачиваться особо умным компилятором в показ MessageBox() (в т.ч. из консольного приложения - встречал) и прочие гадости. Известные ведь грабли, проще написать свой макрос с предсказуемым действием, чем в сотый раз на них наступать.
Если что - я этот сами-знаете-какой-компилятор, разумеется, не оправдываю.
no subject
no subject
Впрочем, это уже холивор.
no subject
проблемы винды
> nanomsg
> zeromq
ложе с пауками
говноедствуем?
no subject
Оно, впрочем, на любые необработанные исключения вылазит, если SetErrorMode c флагом SEM_NOGPFAULTERRORBOX не вызвать.
no subject
no subject
no subject
Например, как организовать прокси в этой архитектуре, и чтобы без потери данных?
Как сделать так, чтобы при изменении топологии сети (или просто при внешних интернетных клиентах) у тебя сендер не тёк, и не слал данные "не туда"?
Как поймать отключение клиента, чтобы сразу сообщить ошибку сендеру, а не через таймаут?
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Или, как ironmq воще в облацех?:)
no subject
no subject
Да уж, и правда не работает, а вот ZeroMQ вроде запустилось на XP, придётся пока на нём остановиться...
no subject