Re: xmalloc string functions
- From: Jeffrey Stedfast <fejj@xxxxxxxxx>
- Date: Sun, 03 Feb 2008 00:57:44 -0600
On Thu, 31 Jan 2008 11:44:57 +0000, Richard Bos wrote:
ymuntyan@xxxxxxxxx wrote:
But it's not true, there are ifs and buts. Using glib, you *can* do
stuff when malloc() fails. Yes, using glib all you sensibly can do on
malloc() failure is some sort of emergency work and quit. If your
application requires more, then you don't want to use glib, that's it.
But I claim that for 'regular' desktop applications that is quite
enough.
If your regular desktop application is a clock, perhaps. If it holds any
user input, and for this the application can be as simple as a
calculator, it is not nearly enough. Consider how irritating it would be
to type half a dozen numbers, of twenty digits each, and a handful of
operations, only to have your application crash because it could not get
the memory for that last comlpex calculation. At the very least, your
app should put up a message box saying "Out of memory - could not
compute"
what if the system doesn't even have enough memory to pop up such a
dialog? Likely it'd take far more resources to display said dialog than
it would take to make the calculation ;-)
, and then let you copy the previous twenty-digit result into
another document for safe keeping.
ah, but that also requires a clipboard memory buffer be allocated... but
you have no memory left ;-)
Sorry to be a smart-ass here, but you clearly have not thought about this
problem in the context of the average desktop application.
In a small daemon, if you get a malloc() failure, you have a lot more
options open to you than you do in a graphical desktop application
because you can do a lot more with very small amounts of memory (or none
at all).
A few examples:
- start dropping idle client connections (which would likely not require
any /new/ allocations) until you have enough memory to do the critical
operation you need to do
- print an out-of-memory or "sorry, can't do that right now" error to the
client socket (or terminal) which would likely not require any new memory
allocations (error strings could be static)
- wait until memory becomes available
On the other hand, say, a word processor application, if the user
requests some sort of action and a malloc() fails for 12 bytes, what is
it supposed to do?
If the documents the user has open have already-opened file descriptors,
the app might be able to save them before going down - but:
1. it certainly doesn't have the option of displaying an error dialog.
2. if any of the files are unnamed or otherwise would require any of:
a) filename generation (would require string building)
b) file descriptor opening (which takes memory)
c) user-interaction (this one is right out)
the application would certainly not be able to save the documents at that
point...
3. can't simply wait because that would be a "hang" which is likely to
cause the user to kill it anyway.
But no, it crashed, taking not just
the final computation but also all intermediate results with it. Now you
have nothing, when you _could_ have had something to work from. Thank
you, glib.
Richard
Feel free to fix it?
Oh wait, I forgot that this whole thread is actually a pissing contest
more than anything else, so that people who don't actually write desktop
applications can feel superior to those who do.
Jeff
.
- Follow-Ups:
- Re: xmalloc string functions
- From: Flash Gordon
- Re: xmalloc string functions
- Prev by Date: Advice on how to return a list of values
- Next by Date: Re: Advice on how to return a list of values
- Previous by thread: Re: xmalloc string functions
- Next by thread: Re: xmalloc string functions
- Index(es):
Relevant Pages
|
