Is "Out of Memory" a recoverable error?
sean at invisibleduck.org
Wed Dec 3 10:17:43 PST 2008
== Quote from Leandro Lucarella (llucax at gmail.com)'s article
> Walter Bright, el 2 de diciembre a las 04:13 me escribiste:
> > I asked this over on stackoverflow.com to see what people using other languages
> > have to say, as well as the D community. The reason I ask is to see if memory
> > allocation can be allowed in functions marked "nothrow".
> > http://stackoverflow.com/questions/333736/is-out-of-memory-a-recoverable-error
> I think all the things said in this thread makes sense (adding callbacks
> to the garbage collector, adding a way to ask for memory that don't throw
> if the memory can't be allocated), but I think this don't cover all the
> possible scenarios.
> For example, I'm working on a softswitch (unfortunately no in D). Lets say
> we have a really bad moment and all the subscribers want to talk at the
> same time and we don't support that workload. Lets say our memory is
> exhausted and a new call arrive. A new allocation is done somewhere deep
> inside the call logic, so the PRE COLLECT callback is called. No memory
> can be reclaimed, so the GC runs a collection. Still no memory. POST
> COLLECT and CRISIS are called too without success. My softswitch is down,
> I lost all the current calls. This is not good for business. What I really
> wanted to do is to catch the memory error as shallow in the call logic as
> possible and drop only that current call, leaving all the current
> established calls intact.
The same could be said of any unexpected error in such an application. Assuming
that you're doing call processing in a multithreaded app as opposed to dedicating
a process per call (as in Erlang) then you'll have to use try/catch blocks carefully
to perform the necessary cleanup at each stage, re-throwing exceptions you don't
intend to handle.
> So what can I do? Should I manually check each and every allocation in all
> the call logic? I think that's unacceptable.
Agreed. The point of exceptions is to avoid the need to verify the result of every
operation and to avoid duplication of recovery code.
More information about the Digitalmars-d