[ILUG] signals and c++

[Kenn Humborg]

> 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. 

The SIGPIPE issue is really best handled in an OS abstraction layer.

Dealing with the plugin stuff properly almost always ends up
re-inventing CORBA or COM :-)

> 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(). 

<RANT>
I couldn't believe this was necessary until I read the 
shmctl manpage:

   The user must ensure that a segment is eventually 
   destroyed; otherwise its pages that were  faulted
   in will remain in memory or swap.

Who the fsck designed this?  It wasn't Sun, was it?
Whatever happened to reference counting?  At least 
VMS's global sections could be either temporary or
permanent.  If you created a temporary section then 
it was automatically deleted when the last process
referencing it unmapped it, which happened as part
of image rundown or process deletion, no matter how
the process died.
</RANT>

> Not deleting tmp files, though use of tmpfile() would sort that one 
> out. 

Yes.

> 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.

Isn't that up the the transport layer between Xlib and the
X server to worry about.  If it's a stream socket connection
(Unix-domain or TCP) then the OS on the client side will
close the connection when the process exits.  Server sees this
and cleans up.  If it's a shared memory connection, then I guess
the shmctl() breakage above holds :-(

> 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.

Agreed.  Given a bit of effort, you could probably come up
with something for each platform that would do the trick.

End result: probably doable, but tricky and definitely outside
the standard.  Would definitely be a useful hack, though.

Mind you, does GCC handle exceptions properly now?  I remember
there used to be issues there (was it that exceptions and
optimization didn't get on, or something?).

Later,
Kenn