Re: xmalloc string functions

Jeffrey Stedfast wrote, On 03/02/08 06:57:
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 ;-)

Have it pre-created together with all the resources it will require, then it doesn't need any more resources.

, 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 ;-)

Have it pre-created, then if you need a larger buffer for the next step and you can't enlarge it you only loose that last step.

Sorry to be a smart-ass here, but you clearly have not thought about this problem in the context of the average desktop application.

Some of us have and have already suggested having and using a buffer that is large enough for the emergency action.

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

Drop that background print-job or spell check that is consuming memory for your desktop app.

- 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)

Pre-create the out-of-memory dialogue and any resources it requires.

- wait until memory becomes available

With an appropriate pre-created dialogue you can do that on a GUI application as well.

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?

Any of the above.

If the documents the user has open have already-opened file descriptors, the app might be able to save them before going down - but:

That is easy to arrange.

1. it certainly doesn't have the option of displaying an error dialog.

Yes it does if it pre-creates it during application start-up.

2. if any of the files are unnamed or otherwise would require any of:

Don't allow them to be unnamed. You can create a name at the same time as creating the otherwise unnamed document.

a) filename generation (would require string building)

Which can be done using a pre-allocated emergency buffer

b) file descriptor opening (which takes memory)

Which could have been opened when the document was created

c) user-interaction (this one is right out)

Which can be avoided or use pre-created dialogue boxes that won't need any more memory than they already have.

the application would certainly not be able to save the documents at that point...

If it was planned for it could. I've come up with ways of dealing with all of the problems. Not to mention the possibility of opening an emergency file at start-up and if it is non-empty using it to recover from the previous crash, or if it is empty using it to write the information to allow recovery.

3. can't simply wait because that would be a "hang" which is likely to cause the user to kill it anyway.

You can't simply wait with most network daemons either. You just make sure you have appropriate resources already available for your recovery strategy.

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?

I don't know about Richard, but I have quite enough work already.

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.

I think it is more annoyance at application we might otherwise consider using that would just throw away our hard work in situations some of us do hit.
--
Flash Gordon
.

Relevant Pages

  • Re: xmalloc string functions
    ... malloc() failure is some sort of emergency work and quit. ... But I claim that for 'regular' desktop applications that is quite ... not get the memory for that last comlpex calculation. ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... malloc() failure is some sort of emergency work and quit. ... application requires more, then you don't want to use glib, that's it. ... the memory for that last comlpex calculation. ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... do stuff when malloc() fails. ... using glib all you sensibly ... can do on mallocfailure is some sort of emergency work and ... the memory for that last comlpex calculation. ...
    (comp.lang.c)
  • Re: Cleanup patterns
    ... program initialization when memory is probably plentiful. ... If malloc() fails later on, you freethe emergency stash ...
    (comp.lang.c)
  • Thank You -- Thomas J. Gritzan
    ... Thomas -- Your suggestion to malloc() out a block of memory was the ... Below are some details of my memory issues ... ... As a work around solution I guessed a ram disk would solve the ... persistence will frustrate the off topic police and give them a target ...
    (comp.lang.c)