Re: bonobo-activation; freeing base services ...
- From: Darin Adler <darin bentspoon com>
- To: Havoc Pennington <hp redhat com>
- Cc: Michael Meeks <michael ximian com>, Gnome Components <gnome-components-list gnome org>, Maciej Stachowiak <mjs noisehavoc org>
- Subject: Re: bonobo-activation; freeing base services ...
- Date: Fri, 26 Oct 2001 16:37:24 -0700
on 10/26/01 4:14 PM, Havoc Pennington at hp redhat com wrote:
> - 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
Not true.
This order turned out to be perfectly sane for Nautilus and in many other
programs that I used in the past. I think we will need to get rid of all
uses of g_atexit in Nautilus, but not for this reason.
> - 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
The exit() function doesn't call itself. I think you are overstating this
problem. It's not an "undefined state". But I see your point that some
programmers might want to be free to call exit at the drop of a hat. I
personally wouldn't use a library that called exit() for me.
> - 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)
Bad problem, yes.
> - they are not particularly guaranteed to run (abnormal exits don't
> call them), so always indicate an unreliable bad hack
You are overstating the case here. A shutdown function is also not
guaranteed to run on an abnormal exit. One is no worse than the other in
this respect. I don't agree that code that runs only on a normal exist is
always 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
Bad problem, yes.
> - there is no way to remove an atexit() function once it's installed
Inconvenient, but no big deal. This has never been a practical problem for
me.
> atexit() == bad hack. File it away with longjmp() under C Library
> Booby Traps and Stupid Ideas.
I think you overstate the case.
But since you feel strongly about it, you should convince Owen and Tim to
deprecate g_atexit in glib and maybe put some words to this effect in there
as a public service.
Anyway, we are missing the main point here. Aren't shutdown functions just
as bad as init functions? And you are always preaching against init
functions. Instead of looking at atexit itself, perhaps we should be looking
at atexit vs. shutdown functions.
-- Darin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]