Re: A solution for the allocation failures problem

[snips]

On Thu, 07 Feb 2008 20:31:05 +0000, Herbert Rosenau wrote:

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.

Scheduler or no, it seems to me than an implementation which does this
may in fact be non-conforming.

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.

As I said, it depends on the nature of the failure. If the code at that
point _does_ have the info, it can in principle at least try. If nothing
else, when giving up, it should do just that: give up. Not take the
entire freaking application with it.

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.

Again, not necessarily. Suppose I'm writing an allocator such as
Malcolm's xalloc. Nothing wrong with his basic notion of "signal user"
or some equivalent (it could be passed a pointer to a notification
function which it could call, which in turn might try to free resources)
before trying again; it's just that if this step doesn't work, it dies
instead of reporting a failure. *That* part I have issues with.

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.

Or functions, plural. No reason that if you're 9 levels down the call
tree, seven of them might not have things to do in the recovery process.

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.

No, there are two options: do exactly that, which is what I suggested, or
do what Malcolm et al seem bent on doing: crashing and burning.

It really is an option. Careless, sloppy, ill-conceived and potentially
disastrous, but it is still an option.

Crashing and burning is no idea I would even evaluate.

Unless one has actually exhausted the alternatives: no UI, so you can't
alert the user. No disk space left, so you can't save. Etc. At some
point you do have to simply give up; I just can't agree with it being the
_first_ choice, rather than the _last_.

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.

Maybe, but good goat, talk about a case of penny wise, pound foolish.

Look, my customers are scold me that I'm pedantic - but on other hand
they come back again with new jobs because I'm pedantic.

Pedantically speaking, no they don't, they come back again because you
get the job done effectively. :)

.

Relevant Pages

  • Re: How to release heap memory that is marked as free
    ... As I said, fragmentation is a very serious problem, and one of the most serious problems ... my allocator was accused of using massive amounts of memory. ... I'm going to have to re-think the memory allocation that I'm ... process's 'working set'. ...
    (microsoft.public.vc.mfc)
  • Re: [PATCH 00/28] Swap over NFS -v16
    ... memory they can consume. ... So we need the extra (skb) ... included in the reserve? ... if the allocation had to dip into emergency reserves, ...
    (Linux-Kernel)
  • Re: Memory leak with CAsyncSocket::Create
    ... read my essay on how storage allocators work. ... Create method is consuming system memory that is not released back to ... The memory consumption is either shown as "Mem Usage" on the Task ... many levels of allocation going ...
    (microsoft.public.vc.mfc)
  • Re: OT: C++ overloading operators
    ... dynamic allocation, no matter how many "clever tricks" are used... ... though there's enough memory in the system, ... all these "flexible data types" map into CPU command ... The computing environment is completely ...
    (comp.dsp)
  • Re: HLA Lib
    ... All memory allocation is freed up when the process quits. ... reduce need to resize blocks for 98% string operations. ... HLA strings already consume. ...
    (alt.lang.asm)