[ILUG] signals and c++

[Caolan McNamara]

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 28.01.00, 17:24:04, "Kenn Humborg" <kenn at bluetree.ie> wrote regarding 
RE: [ILUG] signals and c++:

> For asynchronous signals like SIGINT, it really depends on what
> you are trying to do.  What are you trying to achieve by ensuring
> that destructors get called?

> o  Are you trying to ensure that resources get deallocated?
>    That doesn't matter if the process is going to be killed.
>    (See note below on affecting stuff outside the process.)
>    If the signal will be handled and ignored, then it doesn't
>    matter because the code won't notice it.

> o  If you want to use a signal to partially unwind the call
>    stack, and use destructors for resource deallocation and
>    cleanup, then it's really tricky.  This is really the
>    only case that requires further thought.

What particularly bugs me are the synchronized signals such as SIGPIPE 
and so forth. It would be nice to be able to protect a call on an 
dlopened plugin object with a SEGV exception handler, but that might 
be pushing the boat out a bit far. 

But there are a load of cases where an asynchronous signal that causes 
an exit and bypasses destructors that would do some resource release 
that would be useful for the system, but which are not examples of 
badly designed resource allocation issues. Things that while maybe not 
critical to the system, but do leave cruft and general disarray about 
the place. e.g. Using shmget and exiting without a deleting shmctl(). 
Not deleting tmp files, though use of tmpfile() would sort that one 
out. X windowing apps that might like to cleanly XUnmapWindow() 
themselves from the screen, and not leave big blank canvases which the 
Xserver leaves around for a while until it cops that the app is gone 
etc etc.

Some sort of solution might be possible for apps with message queues 
by making the signal handler empty the queue and insert a quit message 
onto it, and then leave it up to the app to come across it in the near 
future and act on it. But thats hardly ideal.

It is just a pity that there doesn't appear to be a nice way to hook 
signals and c++ together neatly, I think theres a strong case for 
being allowed squidge the bastards into exceptions.

C.