On Wed, 03 Dec 2008 08:34:43 -0500, Leandro Lucarella <[EMAIL PROTECTED]>
wrote:
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.
So what can I do? Should I manually check each and every allocation in
all
the call logic? I think that's unacceptable.
I think this scenario apply to each client-server application that needs
to stay alive even with high workloads, as the expense of dropping some
connection/client (web servers or web applications for example, as
someone
said in stackoverflow.com).
That's a good point/use case. However,
1) Many client-sever applications seperate each client into a logical
thread of some kind. And inside this thread, out of memory is not
recoverable.
2) One can still catch an error if need be.
