Я пытаюсь установить "обработчик сбоя" для многопоточного приложения C OSX Carbon .
В Windows я могу легко использовать простой и эффективный __ try {} __except {} SEH для Windows , который прекрасно работает. (Обратите внимание, что это несвязанных с C ++ исключений, это конструкции более низкого уровня C!)
Это очень связано с вопросом, который я задавал на SO ранее :
а также на более старый вопрос SO .
Ответ, похоже, заключается в том, чтобы использовать setjmp () перед каждой областью кода, а затем использовать обработчик сигнала для longjmp () назад, если произошел сбой.
Но реализация этого нетривиальна .. из-за многопоточности! Идиома __try {} __except {} в Windows является поточно-ориентированной и просто работает. Но, очевидно, setjmp не является потокобезопасным.
Так как бы выглядела реализация?
Я продолжаю думать, что мне придется реализовать некоторое локальное хранилище потоков. В начале я инициализирую setjmp, сохраняя состояние среды в локальном буфере потока, затем обработчик сигнала должен будет снова найти данные среды, просматривая локальную область потока. Однако ни Google, ни SO не показывают никаких доказательств того, что это правильная стратегия, тем более что setjmp () задокументирована как небезопасная для потоков.
И разве локальному хранилищу потоков не понадобится каждый поток регистрировать себя и выделять память (для хранения данных среды) и освобождать ее при уничтожении потоков?
Я надеюсь, что смогу создать макрос, который обернет все это, так что в OSX мой код __try __except будет работать.
Итак, как мне сделать многопоточный обработчик аварийного восстановления OSX, используя сигналы и setjmp?