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

[Maciej Stachowiak <mjs noisehavoc org>]

On 26Oct2001 07:14PM (-0400), Havoc Pennington wrote:
> 
> 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 in the opposite of the order in which they were installed. If
each library installs its atexit() handlers when initialized, and
initializes all libraries it may need when shutting down before
installing the handler, this will be the right 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)

You mean in case of an error on exec()? There are still other reasons
its more correct to call _exit() instead of exit().
 
>  - they are not particularly guaranteed to run (abnormal exits don't
>    call them), so always indicate an unreliable bad hack

The gnome-vfs shutdown function, which I hope to turn into an atexit()
handler for GNOME 2.0, cancels any outstanding threads. If you don't
call it you can leak threads and the program does not exit
properly. However, being killed by a signal will already kill all
threads.

So in this case I think an atexit() handler is exactly the right
approach.
 
>  - 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

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

But you usually don't need to, or if you do, it wouldn't be hard to
write an atexit wrapper that registers a single real atexit function and 
 
> atexit() == bad hack. File it away with longjmp() under C Library
> Booby Traps and Stupid Ideas.

Shutdown functions that are necessary for correct operation of the
program are even worse, because programers will forget to call them
before calling exit(), leading to obscure bugs. If the library needs
to do shutdown processing, I think it should use an atexit() handler
rather than an explicit shutdown function.

You seem to have strongly held opinions about the issue but I don't
find them very convincing given that they are low on specifics and I
have never run into actual problems with shutdown functions myself.

Personally, I would rather have neither atexit handlers nor shutdown
functions, but given the choice, I prefer the atexit handler.

 - Maciej