Ada_Ru форум

Обсуждение языка Ада

[ada_ru] Re: Переключение­ обр­аботчиков сигналов н­а гра­нице вызовов библиотек

Оставить новое сообщение

Сообщения

Иван Леваше
[ada_ru] Re: Переключение­ обр­аботчиков сигналов н­а гра­нице вызовов библиотек
2017-07-13 03:31:02
22.09.2014 16:16, Maxim Reznik [email protected] [ada_ru] пишет:
> С этой точки зрения в Linux все чисто.
>
> Генерация и обработка исключений определяется в ABI, см. например
>
> System V Application Binary Interface
>
> AMD64 Architecture Processor Supplemen
>
> http://www.x86-64.org/documentation/abi.pdf
>
> GNAT, C++ и пр. следуют этим соглашениям, никаких обработчиков переключать не нужно.
>

Пример этот оказался очень плохим, потому что в C++ поведение при 
делении на ноль (SIGFPE), плохих инструкциях и неудачных обращениях к 
памяти (SIGSEGV) не определено и не приводит к вызову исключений. И то, 
что хотелось бы посмотреть, просто отсутствует.

А с тем, что случается, если вызывать исключения и ловить в одной 
языковой компоненте, проблем нет, там хоть какой longjmp или ZCX, можно 
брандмауэр сделать, и эти детали между компонентами не просочатся.

Проблема-то в том, чтобы разъименовывать null и делить на ноль в разных 
языках программирования, но чтоб везде реакция была адекватная языку. 
Поэтому я правильно выбрал пример с Free Pascal как с языком, 
сопоставимо хорошим с Адой, а пример с C++ — неверен.

Ковырнул, как это сделано в Delphi 10.2 для Linux и нашёл в 
System.SysUtils.pas такое:

> External exceptions, or signals, are, by default, converted to language
> exceptions by the Delphi RTL.  Under Linux, a Delphi application installs
> signal handlers to trap the raw signals, and convert them.  Delphi libraries
> do not install handlers by default.  So if you are implementing a standalone
> library, such as an Apache DSO, and you want to have signals converted to
> language exceptions that you can catch, you must install signal hooks
> manually, using the interfaces that the Delphi RTL provides.
>
> For most libraries, installing signal handlers is pretty
> straightforward.  Call HookSignal(RTL_SIGDEFAULT) at initialization time,
> and UnhookSignal(RTL_SIGNALDEFAULT) at shutdown.  This will install handlers
> for a set of signals that the RTL normally hooks for Delphi applications.
>
> There are some cases where the above initialization will not work properly:
> The proper behaviour for setting up signal handlers is to set
> a signal handler, and then later restore the signal handler to its previous
> state when you clean up.  If you have two libraries lib1 and lib2, and lib1
> installs a signal handler, and then lib2 installs a signal handler, those
> libraries have to uninstall in the proper order if they restore signal
> handlers, or the signal handlers can be left in an inconsistent and
> potentially fatal state.  Not all libraries behave well with respect to
> installing signal handlers.  To hedge against this possibility, and allow
> you to manage signal handlers better in the face of whatever behaviour
> you may find in external libraries, we provide a set of four interfaces to
> allow you to tailor the Delphi signal handler hooking/unhooking in the
> event of an emergency.

Посмотрел в OpenJDK, а в Java тоже нельзя пройти мимо таких плохих 
ситуаций, и там тоже свой обработчик сигналов ставится.

То есть, действительно всё настолько плохо, насколько я думал. На 
Виндоуз всё просто работает, на самых разных языках можно библиотеки COM 
писать, и деление на ноль, и разъименование null дойдёт куда надо, и всё 
это легко и непринуждённо, надо только брандмауэры ставить, но это ещё 
куда ни шло.

А на Линуксе такая простота только снится. Обработчики сигналов 
глобальные, внутри потока средствами OS переключать не получится, надо 
обработчиком ставить мультиплексор, который будет знать, в какой RTL 
переслать. Видел такие решения на pthread specific.

А про этот свеженаписанный мультиплексор никто, конечно, знать не будет, 
и все RTL ставить обработчики будут либо через глобальный sigaction, 
либо никак, значит, надо для каждого RTL научиться выуживать этот 
обработчик, чтоб поставить именно в мультиплексор, а не глобально.

О том, что всё настолько плохо, информации не было, как я понимаю, 
потому что совмещение делалось почти всегда так, что по одну сторону 
ущербный язык вроде C++, и для такого ущербного языка это нормально — не 
быть в курсе, что будет в случае деления на ноль.



По крайней мере, объём работ понятен.

С уважением,
Левашев Иван,
Барнаул

-- 
If you want to get to the top, you have to start at the bottom
Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти