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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
