bernds_cb1 at t-online.de
Sun Jun 8 18:34:41 UTC 2008
Denys Vlasenko wrote:
> If this program wants to not be killed by OOM, it needs to install
> the handler for this situation. It is not difficult at all.
But this ignores the fact that there's a large body of software out
there _which wasn't written against uClibc and whose authors have never
heard of it_. It's completely unrealistic to expect programs to
install such a handler, since it does not exist in the standards that
people actually write code against.
If all that ever ran on uClibc-based systems was busybox, maybe I'd
agree with you.
> No, my argument is twofold:
> 1. Minority of people who are careful enough to handle OOM coditions
> correctly will not be deterred by the need to have a tiny speck
> of uclibc-specific glue:
See above. Completely unrealistic expectation as to the level of
control we have over users.
> 2. Most of the programs do not handle OOM situation correctly anyway:
"Other people screw up, so let's do the same". It's bad enough to have
applications misbehave, but do we want to build unreliability right into
> Again, my point is: if the program dies on OOM because it
> is badly written and does not expect NULL from malloc,
> why we are avoiding malloc inside libc as a plague?
- two wrongs do not make a right.
- we're implementing a specification where malloc is documented as
being allowed to return NULL, and certain functions are _not_
documented as allowed to call exit, and where people therefore have
the realistic expectatino that this is not going to happen.
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
More information about the uClibc