Re: out-of-mem handler

On 15 Feb 2000, Havoc Pennington wrote:

> Tim Janik <> writes:
> > that's just a random game, you try to put some questionable handling
> > for *some* case where a rare error could take effect. the point is,
> > you either need to do this for libc as well or not do anything at
> > all.
> That isn't true at all. If you can avoid 50% of crashes that's much
> better than avoiding 0% of crashes.
> > being held during your malloc sleep etc., there are probably a lot
> > of else situations where you'd rather bail than sleep.
> > 
> gnome-session bailing is catastrophic; sleep() can't possibly cause
> worse results. If gnome-session bails your whole session implodes.
> It is totally bogus to say that because you can't recover 100% of the
> time you shouldn't try to recover. It's just not true. If users avoid
> 50% of session crashes then users are happier.
> Yes if you can think of a way to recover 100% of the time that might
> be nice, but I can't think of a way.

you make it sound like not having this sleep-in-malloc hack would cause
crashes in gnome-session, which is just not true. first, g_malloc() doesn't
*crash* on out of mem conditions, but gives an error message and aborts the
program, this is way different than random untracable and unproduceble
crashes. second, as far as i know, gnome-session doesn't allocate huge
amounts memory, so if it encounters out-of-mem conditions, all other apps
will be out of mem as well, i.e. your window manager, the x server, etc...
it's not like only gnome-session had this problem in such situations.

at the bottom line, you are trying to partly-patch a fairly rare error
condition in one program with doubtfull benefit, by sugesting to add an
unreliable hack to glib.

that sounds really questionable to me, to say the least.

(note that i'm not telling you that you should keep your hands off of
gnome-session, just that glib is very probably the wrong place to
hack up. rather, go for direct malloc/realloc/free interventions on
platforms that support it, if you are really convinced of the benefits
of your approach)

> Havoc


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]