> 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().
I couldn't believe this was necessary until I read the
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.
> Not deleting tmp files, though use of tmpfile() would sort that one
> 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?).
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!