Re: bonobo-activation; freeing base services ...

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes: 
> I have the same comment as for the last patch - any reason this can't
> be an atexit function? I haven't actually reviewed this change in
> detail (or the last one), I'll try to read over it sometime tomorrow
> (unless a version revised to use atexit beats me to it).

Yes - what are you thinking. atexit() functions are a terrible idea,
especially in a library.
 
 - they run in undefined order, for all practical purposes (especially
   in a lib, because the app and other libs don't know when the lib is
   installing the function) - yes I know they run in reverse order of
   install, but for large codebases using atexit this doesn't end up
   being any sane order

 - they run when the app is in an undefined state, because when people
   call exit() they aren't thinking "oh some wacky reentrancy will go
   on now", and because of the undefined order issue

 - they force apps to use _exit() when they do a fork/exec (this FAQ
   is why we ripped atexit() usage out of GTK, well, this and the fact
   that atexit() is an awful idea)

 - they are not particularly guaranteed to run (abnormal exits don't
   call them), so always indicate an unreliable bad hack

 - there's a fixed limit to the number of them you can have on some
   platforms, Nautilus already overruns it, reported to GLib
   bugtracker recently, so it isn't portable

 - there is no way to remove an atexit() function once it's installed

atexit() == bad hack. File it away with longjmp() under C Library
Booby Traps and Stupid Ideas.

Havoc