Написание обработчиков сигналов для общих библиотек или DLL?

У меня есть приложение A (от какой-то компании X). Это приложение позволяет мне расширять функциональность, позволяя мне писать свои собственные функции.

Я сообщаю приложению A, чтобы оно вызывало мои пользовательские функции в файле конфигурации приложения A (именно так оно узнает, что приложение A должно вызывать пользовательские функции). Приложение A использует указатели функций, которые я должен зарегистрировать в приложении A до вызова моих пользовательских функций.

Если в моих написанных пользователем функциях в производстве есть ошибка или ошибка, приложение A перестанет работать. Например, если у меня есть ошибка сегментации в моих написанных пользователем функциях.

Таким образом, приложение A загрузит мою написанную пользователем функцию из общего файла DLL. Это означает, что мои написанные пользователем функции будут выполняться в адресном пространстве процесса приложения A.

Я хочу обрабатывать определенные сигналы, такие как ошибка сегментации, деление на ноль и переполнение стека, но приложения A имеют свои собственные обработчики сигналов, написанные для этого,

Как я могу написать свои собственные обработчики сигналов для перехвата исключений в моих написанных пользователем функциях, чтобы я мог изящно очищать, не затрагивая большую часть приложения A? Поскольку мои пользовательские функции будут вызываться в процессе приложения А, ОС будет вызывать обработчики сигналов, написанные в приложении А, а не мои пользовательские функции.

Как я могу это изменить? Я хочу, чтобы ОС вызывала обработчики сигналов, написанные в моих функциях, но только для сигналов, вызванных моими функциями, которые по своей природе асинхронны.

Примечание. У меня нет исходного кода приложения А, и я не могу вносить в него какие-либо изменения, поскольку оно контролируется другой компанией.

Я буду использовать C и только C на платформах Linux, Solaris и, возможно, Windows.


signal-handling
person linkedlist    schedule 04.01.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Вы не указываете, с какой платформой вы работаете, поэтому я отвечу за Linux, и это должно быть справедливо и для Windows.

Когда вы устанавливаете обработчики сигналов, используемый вами системный вызов возвращает предыдущий обработчик. Это делается для того, чтобы вы могли вернуть его, как только вы больше не заинтересованы в обработке этого сигнала.

справочная страница Linux для signal
запись MSDN по сигналу

Поскольку вы являетесь общей библиотекой, загруженной в приложение, у вас не должно возникнуть проблем с управлением обработчиками сигналов. Просто не забудьте переопределить необходимый минимум, чтобы уменьшить вероятность нарушения работы самого приложения (некоторые приложения используют сигналы для асинхронных уведомлений).

person Leeor    schedule 04.01.2009

arrow_upward
1
arrow_downward

Самый чистый способ сделать это — запустить код вашего приложения в отдельном процессе, который взаимодействует со встроенным общим кодом DLL через какой-либо механизм IPC. Вы можете обрабатывать любые сигналы, которые хотите, в своем процессе, не затрагивая другой процесс. Обычно упомянутые вами условия (ошибка сегмента, деление на ноль, переполнение стека) указывают на ошибки в программе и приводят к ее завершению. Вы мало что можете сделать, чтобы «справиться» с этим, кроме исправления основной причины ошибки.

person codemaker    schedule 01.11.2016

arrow_upward
-5
arrow_downward

в C++ вы можете поймать их, поместив свой код в try-catch:

try
{
   // here goes your code
}
catch ( ... )
{
   // handle segfaults
}
person Stefan    schedule 04.01.2009
comment
Вы не можете перехватывать сигналы с помощью обработчиков исключений. Вы можете ловить только исключения. - person codemaker; 01.11.2016
comment
да, вы можете с тремя точками, и если вы скомпилируете с /EH : msdn.microsoft.com/en-us/library/1deeycx5(v=vs.80).aspx - person Stefan; 02.11.2016
comment
Интересно, я не знал об этом. Хотя это специфично для Windows, и в исходном плакате указано, что они используют C. - person codemaker; 02.11.2016