Bug in touchForeignPtr?

[Keean Schupke]

How can I put this, it is a "best efforts" approach - it does its best 
to run the
finalizers, even after a segmentation fault... however some of the 
pointers may
be messed up... If the cleanup causes a segmentation fault (sometimes called
a double bus fault) then we have to abandon the cleanup. With our semaphores
we are actually quite clever, in that the at_exit routine is set 
containing the
semaphore ID as a constant, so it should always be runnable...

What I am suggesting is that every effort should be made to clean up, 
just because
there are some circumstances (which should be rare) in which it cannot 
happen, does
not mean you shouldn't try...

    Keean

Glynn Clements wrote:

>There isn't any way to *guarantee* that something is run upon
>termination. The program may be terminated due to SIGKILL (e.g. due to
>a system-wide lack of virtual memory). If you run out of stack, you
>may not be able to call functions to perform clean-up.
>
>  
>
>Also, if the program crashes, handling the resulting SIGSEGV (etc) is
>likely to be unreliable, as the memory containing the resource
>references may have been trashed. Calling remove() on a filename which
>might have been corrupted is inadvisable.
>
>Also, at_exit() isn't standard. atexit() is ANSI C, but that is only
>supposed to be called for normal termination (exit() or return from
>main()), not for _exit() or fatal signals.
>  
>