apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject Re: cvs commit: apr/memory/unix apr_sms.c apr_sms_trivial.c sms_private.h
Date Sat, 07 Jul 2001 23:01:35 GMT
On Sat, 7 Jul 2001 rbb@covalent.net wrote:

> On Sat, 7 Jul 2001, Justin Erenkrantz wrote:
>
> > On Sat, Jul 07, 2001 at 12:26:32PM -0000, dreid@apache.org wrote:
> > > dreid       01/07/07 05:26:32
> > >
> > >   Modified:    include  apr_sms.h
> > >                memory/unix apr_sms.c apr_sms_trivial.c sms_private.h
> > >   Log:
> > >   Add the abort function into sms.  This is largely to keep compatability
> > >   with pools and at present we don't do anything more than get/set, but
> > >   that's easily fixed.
> > >
> > >   Question is, do we still want this capability?
> >
> > I don't think there is any benefit to this.  But, someone else might
> > be able to chime in and say why we need this functionality.  -- justin
>
> This MUST stay.  The reason is simple.  A well behaved library will not
> exit, or print a message to stderr.  However, because APR needs to
> maintain backwards compat with Apache 1.3, when we can't allocate memory,
> we print to stderr, and abort.
>
> Unless there is another way to use APR and provide both options, the abort
> function must remain.

what's it really matter?  trying to clean up from OOM is near impossible.

the task will be shot on linux or anywhere else with optimistic memory
allocation in many situations.

linux 2.4 changes the OOM situation slightly, but only in the details as
to which task gets shot.  (not necessarily the one which tried to access
the last available free page.)

and like i said in my other message, you have no idea from NULL vs.
non-NULL as to whether you're out of memory yet.  in fact, malloc may
brk() to get more memory, then segfault while trying to lay down its
structure into that memory.  (linux malloc of >=128kb blocks use mmap
directly and they're page aligned with no malloc structures, so the
segfault doesn't happen until the application touches it... for the "why"
of this study the mremap() syscall and try remallocing big regions on
linux :)

oh also, you might fault trying to grow the stack and that could take the
task out.

also, a box which is OOM desperately needs memory in order to function.
either your task is going to die, or something else is.  the box is
probably so deep into swap that it's unuseable, and the faster you die the
better for everyone.

one might ask "but what about all those resources i need to unwind and
release" ... and to that i'll just say:  power failure.  if resource mgmt
is so important then you've already considered power failures and you've
concluded that you need to use transaction logging techniques.  (this is
also why i really like things which are freed up and released properly on
their own when a process exits... like kernel-based locks, and not like
pthread mutexes :)

i kind of gave up on memory allocation checking.  i'd consider it if i was
coding in ada or some language with appropriate exception mechanisms.
but not in C.

but i could just be jaded :)

-dean


Mime
View raw message