Re: A solution for the allocation failures problem
- From: "Herbert Rosenau" <os2guy@xxxxxxxxxxxxx>
- Date: Thu, 7 Feb 2008 20:31:05 +0000 (UTC)
On Wed, 6 Feb 2008 02:02:24 UTC, Kelsey Bjarnason
<kbjarnason@xxxxxxxxx> wrote:
1) At program start, allocate a big buffer that is not used elsewhere
in the program. This big buffer will be freed when a memory exhaustion
situation arises, to give enough memory to the error reporting routines
to close files, or otherwise do housekeeping chores.
Releasing such buffer may not effect the ability of malloc() to return
or not memory at all.
In theory, at least, it should - as the definition of free explicitly
says it releases the memory for subsequent allocation, which means
(presumably) that a conforming implementation cannot hand it back to the
OS - it wouldn't be available for allocation if it's being used elsewhere.
In practise it does not - because immediately after free() has oned
its work the sheduler gives another thread the CPU and that thread has
nothing better to do than to eat the released memory for its own job.
Crappy because a simple return NULL to the caller of the function
calling malloc() is the only manageable solution to recover from that
failture as only the caller or its caller will be able to win enough
memory to continue successfully.
Dealing with the failure "at point of failure" isn't inherently evil.
For example, if the calling code is trying to, oh, send a packet across
the network and the connection has failed, it might be nice if it tried
to re-establish the connection before giving up. Depends on the app, but
it's not a wholly unreasonable concept.
No, because at that point the app knows nothing than the handle that
holds not enough information reopen the session. You'll have to inform
some higher instance that the current connection is broken and let it
do the reconnect on the sybolic name as the break may occure because
something in the path may have changed and even the IP is out of order
now.
I *think* this is the guiding logic here; try to allocate, if it doesn't
work, try to recover, if you can't, bail.
In terms of dealing with things "at point of failure", where you probably
have the best bet of actually coping with the problem, it's not so bad a
concept.
No, mostenly at point of failture you only knows that there is a
failture but you lacks off information how get it repaired. Your
caller or even its caller will have more knowledge about the
abstracts, so it will be able to recover.
Where it becomes bad, for me, is that the failure strategy is to simply
throw in the towel, without giving the caller any chance to do anything
about the situation.
It's much simpler to undo anything you've done in the failing action,
go back to the caller with the error you failed and let it find its
own strategy up the chain until a more intelligent function knows
better what to do on the current situation.
In an example I used elsewhere, if my word processor can't allocate
enough memory to load a fourth document, I have at least two options:
crash and burn, or simply accept I can only work with three documents
right now.
No, there is only one option: accept that you can NOT open another
document, tell the user the fact of 'currently too low on resource
xxx' and let the user decide what he likes to do - including another
try to get what he want.
Crashing and burning is not so good if I have three documents open with
edits I'd like to keep; I'd much prefer simply getting a failure
indicator - such as NULL instead of a valid pointer - and coping with it
in the calling code. If nothing else, I can save the existing documents
before bailing.
Crashing and burning is no idea I would even evaluate. Let the user
decide what action may give you more free resources. He may save a
document (temporarey) to give you a bit more resource to get the job
he want, he may decide to shutdown the procram completely to come back
later when he thinks that the mashine has more free resources, he may
simply establish any change he had done now to get the undo buffers
free, he may shutdown one or more other applications or other tasks of
your app.......
And all that because the programmer was to braindead to write a single
if.
You really have to wonder. Do these people actually just blindly assume
every file open works? Every file read or write works? Every network
connection establishes, every packet transmits?
I suspect not; I suspect they do, in fact, check these things as a matter
of habit. Memory allocation, though, invokes some weird sort of black
magic which cannot, for some reason, be dealt with in the same way.
I suspect clearly they do because they must save each possible cent on
developement and will decline maintenance too.
I don't get it, and it sounds like you don't, either. Maybe one of 'emLook, my customers are scold me that I'm pedantic - but on other hand
will explain it in terms that involve some sort of consistency: if you
check one sort of resource acquisition as a matter of habit or design,
why is another sort of resource acquisition treated so much differently?
they come back again with new jobs because I'm pedantic.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
.
- Follow-Ups:
- Re: A solution for the allocation failures problem
- From: Kelsey Bjarnason
- Re: A solution for the allocation failures problem
- References:
- Re: A solution for the allocation failures problem
- From: Kelsey Bjarnason
- Re: A solution for the allocation failures problem
- Prev by Date: Re: Treating 'char' Structure Members as Contiguous Bytes
- Next by Date: Re: TUTORIAL
- Previous by thread: Re: A solution for the allocation failures problem
- Next by thread: Re: A solution for the allocation failures problem
- Index(es):
Relevant Pages
|
