Здравствуйте! Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категории: IT. Если вы считаете, что система ошиблась - напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее. Фрэнк, команда ЖЖ.
Ну, x+1 это знаменитая тема. В форте только хорошо :) У всех остальных "ну вот, началось".
Я как-то на эти грабли наехал у доблестной циски. Бойцы, которые ios писали, на тогдашних старших платформах гоняли по шине переменные. Ну там иначе никак - съём весь на центральном cpu, а на местных мелкосхемах только временное хранение. То есть, как положено - по таймеру мы отдали данные мелкосхем на cpu (вам это должно быть знакомо по коммутаторам). А вот когда у них случался crc error (frame relay, на ethernet теперь это фантастика), бойцы ничтоже сумняшеся уменьшали в мелкосхеме счётчик пришедших пакетов. Потому что хватило ума сделать +1 сразу по фронту прихода, а не по итогу. Если ошибка падала после таймера, то следующий таймер (при условии слабого трафика) мог прислать в центральный cpu счётчик на единицу ниже, чем был. Отчего тогдашние заббиксы (точнее крикеты) дурели и думали, что случится overflow :-) Прикольно было на графике видеть выброс, какой физика по жизни дать не могла.
Циска родила только через год и только в S версии
( ... )
в более современных языках для этого есть try...catch, в который и надо заворачивать весь код (чего никто нихрена не делает, оттого и мы наблюдаем вокруг этот горький катаклизм)
Вы знаете, покопавшись в потрохах плюсов, я теперь являюсь местами скептиком раскрутки стека. В первую очередь мне не нравится останов потока по исключению. Это при долгом I/O - источник тормоза.
Окей, окей, тот маленький кусочек кода, который действительно требует высокой производительности, его, конечно, заворачивать в try...catch нехорошо, с этим согласен.
В теории мне нравится методика. Пожалуй даже для массового ПО это лучше, чем ничего. Потому что проверять результат каждой функции мало кто хочет. Да и широкое использование наследия Степанова привело, в общем, к надежде только на исключения. От этого уже не уйти внутри плюсов.
Но вот сигналы. Они перпендикулярны. А в жизни они нам даны, к сожалению. Приходит в процесс ну ладно SIGTERM, подождут сто секунд, не переломятся. Ну а если SIGHUP? А у нас I/O где-то в глубинах TCP-стека. С замершим соединением и перепосылками внутри send (ну или recv, пофиг). Исключение не в курсе, оно ждёт окончания syscall. Вот примерно об этом. На каждый syscall EINTR? Гм, мы вернулись в дедовский Си (с Керниганом и Ритчи :)
Comments 14
Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категории: IT.
Если вы считаете, что система ошиблась - напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее.
Фрэнк,
команда ЖЖ.
Reply
Жизнь научила.
Reply
С default в конце? Одобряю!
Reply
Есть ещё вот такая норкомания
( ... )
Reply
Reply
Ну, x+1 это знаменитая тема. В форте только хорошо :) У всех остальных "ну вот, началось".
Я как-то на эти грабли наехал у доблестной циски. Бойцы, которые ios писали, на тогдашних старших платформах гоняли по шине переменные. Ну там иначе никак - съём весь на центральном cpu, а на местных мелкосхемах только временное хранение. То есть, как положено - по таймеру мы отдали данные мелкосхем на cpu (вам это должно быть знакомо по коммутаторам). А вот когда у них случался crc error (frame relay, на ethernet теперь это фантастика), бойцы ничтоже сумняшеся уменьшали в мелкосхеме счётчик пришедших пакетов. Потому что хватило ума сделать +1 сразу по фронту прихода, а не по итогу. Если ошибка падала после таймера, то следующий таймер (при условии слабого трафика) мог прислать в центральный cpu счётчик на единицу ниже, чем был. Отчего тогдашние заббиксы (точнее крикеты) дурели и думали, что случится overflow :-) Прикольно было на графике видеть выброс, какой физика по жизни дать не могла.
Циска родила только через год и только в S версии ( ... )
Reply
Reply
Вы знаете, покопавшись в потрохах плюсов, я теперь являюсь местами скептиком раскрутки стека. В первую очередь мне не нравится останов потока по исключению. Это при долгом I/O - источник тормоза.
Reply
Но остальные-то, остальные 99,5% кода ?
Reply
В теории мне нравится методика. Пожалуй даже для массового ПО это лучше, чем ничего. Потому что проверять результат каждой функции мало кто хочет. Да и широкое использование наследия Степанова привело, в общем, к надежде только на исключения. От этого уже не уйти внутри плюсов.
Но вот сигналы. Они перпендикулярны. А в жизни они нам даны, к сожалению. Приходит в процесс ну ладно SIGTERM, подождут сто секунд, не переломятся. Ну а если SIGHUP? А у нас I/O где-то в глубинах TCP-стека. С замершим соединением и перепосылками внутри send (ну или recv, пофиг). Исключение не в курсе, оно ждёт окончания syscall. Вот примерно об этом. На каждый syscall EINTR? Гм, мы вернулись в дедовский Си (с Керниганом и Ритчи :)
Reply
Программист ложась спать ставит на тумбочку два стакана: с водой если захочется пить и пустой если нет
Reply
В данном случае три. С чем-то типа колы, пива, водки. Если воду выключат ночью.
И парадокс - так бывает :-)
Reply
a может быть не <, = или > b - его может просто не быть, к примеру
Reply
Leave a comment