Pull to refresh

Comments 11

А вы форум на xakep.ru убрали окончательно и безвозвратно?
Конечно же, нет.

Мы делаем нормальный форум, на более-менее современной платформе. Смотрим в сторону www.discourse.org. Несколько месяцев назад опрометчиво поддались на маркетинговый буллшит и переехали на bbPress. Оказалось, это было ошибкой. Были чудовищные проблемы производительности, как ни кешируй, которые сказывались на работе всей сети сайтов.

Если можете порекомендовать нормальное форумное решение из своего опыта, будем очень благодарны. Обзоры, техдоки — это конечно хорошо, но личный опыт — это всегда ценно. Да и пока не попробуешь под нагрузкой в работе, не поймешь, как оно. Мир форумного ПО нынче не то, чтобы очень динамично развивается, хоть phpBB ставь :).
Discourse очень классный — пользуюсь им на internals.rust-lang.org и users.rust-lang.org. Отзывчивый и удобный интерфейс, на телефоне хорошо работает.

Успехов с переходом! :)
Чет я не понял статью, использование исключений это плохо или хорошо? Или тут просто сравнение методов обработки исключений 32 и 64 битной виндовс только?
Тут описанно как работают исключения OS в винде и как их хендлить если ваш код ездит по памяти.

В linux таких исключений просто нет. Вместо этого ядро присылает сигнал с информацией об ошибке.
А в Линуксе сигнал принимается callback'ом или нужно прокачивать сообщения, как в Windows через подобие PeekMessage, отдельным потоком?
Есть оба способа. Можно указать callback, но такой callback будет вызываться адски ассинхронно, вплоть до того, что может быть вызван например посреди взятии мютекса, оставляя мютекс в невалидном состоянии (до конца обработки сигнала).
Т.е. вызов сигнала для процесса — это что-то вроде вызова прерывания для ядра. Может прилететь совершенно неожиданно. Поэтому в таких хендлерах нельзя использовать обычные примитивы синхронизации типа мютексов или семафоров. Можно получить дедлок, даже если у вас всего один поток в процессе.

Но, к счастью, есть сихнронный способ обработки сигналов. Когда все потоки кроме одного запрещают вызов сигналов, а тот единственный — блокируется на sigsuspend() и ждет сигналов синхронно. Это похоже на PeekMessage
Но в этом случае исключение, относящееся к одному потоку, «прилетит» в другой и его нельзя обработать по месту?
Ну в случае синхронной обработки — да, прилетит в выделенный поток-обработчик.

А как поток который только что вызвал например segmentation fault может потом вызвать PeekMessage что бы узнать что он натворил? Мы же говорим о реально исключительных ситуациях, типа деления на ноль, обращения к несуществующей памяти и т.д.
Так и замечательно — произошло деление на ноль, поток, в котором это произошло, может сам «свернуться», подчистить все ресурсы. Даже при обращении к несуществующей памяти это возможно, т.к. на несуществующий участок может указывать один только указатель, все остальное — верное. Если опять «дыра», будет задействован следующий обработчик, и так до тех пор, пока не убдет найден работающий, либо мы вылетим в системный обработчик.

Я не про PeekMessage, я про SEH систему в Windows против системы сигналов.
Ну тут да, спорить не буду. Мне кажется, что SEH куда гибче и удобней системы сигналов. Хоть сигналы и пытаются периодически допиливать до чего-то более удобного.
Sign up to leave a comment.