Ada_Ru форум

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

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

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

Сообщения

Иван Левашев
[ada_ru] Re: Переключение­ обр­аботчиков сигналов н­а гра­нице вызовов библиотек
2017-07-13 03:31:02

22.09.2014 16:16, Maxim Reznik reznikmm@front.ru [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

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