* Farooq Mela <[EMAIL PROTECTED]> [010222 23:52] wrote:
>
> This is not what I am arguing. I gave a simple example of an xmalloc
> function which does just print an error and exit. However, I've written
> many large applications using this sort of scheme where when allocation
> fails, all sorts of cleanup is performed before the process exits
> (cleaning up & restoring terminal mode, gracefully closing files /
> sockets / etc, syslogging the event, etc). It is hardly ever a simple
> exit as soon as allocation fails.
Here's exactly what's wrong with your idea:
Some internal libc function that _can_ gracefully handle an out
of memory return will not be able to do so if your malloc wrappers
wrest control out from under them.
Honestly, any code is somewhat flawed if it doesn't take extra care
not to have sections where an abrupt shutdown can cause a lot of
damage or inability to recover on restart. However...
Some internal libc functions may attempt an allocation while in the
midst of doing something evil to your program such as fiddling with
signal masks or timers, if you get your "out of memory" callback
and the libc function hasn't had time to restore your normal program
context, you're going to have a world of pain to deal with.
I can't provide any specific examples of this potentially happening,
but I can imagine it being a problem, especially deep within something
like the userland thread library or other complex library.
If you need to deal with asprintf problems, then make an xasprinf
that does the callback in your context, not from deep within libc.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
