[fpc-pascal] re: thanks for major signal handling fix

[Jonas Maebe]

On 20 May 2009, at 21:50, Seth Grover wrote:

> Imagine this scenario. I have an FPC-compiled executable (fpcprog) and
> two FPC-compiled shared object libraries (libfpc1.so and libfpc2.so).
> Each of which installs its own set of signal handlers:

That's not possible. Per process, Unix only supports a single signal  
handler to be installed for a particular signal at any time. Moreover,  
Kylix nor FPC call through to previously installed signal handlers  
(even though they do record them, so you can restore them via the  
UnhookSignal() routine).

> fpcprog does it
> as part of the sysutils initialization code,

Now the program has hooked them and will raise Pascal exceptions based  
on those signals.

> and the .so's do it
> (since rev 13077 was checked up) in "HookSignal(RTL_SIGDEFAULT)",
> which (I suppose?) I would call during the libraries initialization
> code.

Then the last loaded library will have hooked them and raise the  
exceptions.

> Given this scenario, I would like any fatal signals (SIGSEGV, SIGILL,
> etc.) to be handled in the correct try/except block in whatever binary
> it might occur.

For this you need Delphi-style "packages" support. That has nothing to  
do with the patch you are talking about (and if there were packages  
support, that patch would have changed nothing).

The problem you have right now is that the program and each of your  
libraries each contain their own copy of the exception class, and  
therefore do not recognise (Pascal) exceptions raised by any of the  
others. The Pascal exceptions will always be raised by the last one of  
those to hook the signal handlers.

With packages, only one single copy of the exception class could be  
included in the process (the one inside a package), and everyone would  
use that one. Therefore, regardless of who would translate the signal  
into an exception, everyone would recognise this exception instance  
for what it is.


Jonas