Re: bad alloc
On Sep 6, 2:36 am, Adam Skutt <ask...@gmail.com> wrote:
On Sep 3, 7:14 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
I'm not sure what you mean by "the facilities out of the box".
No language that I know provides the logging facilities
necessary for a large scale server "out of the box"; C++
actually does far better than most in this regard. And no
language, to my knowledge, provides any sort of transaction
management (e.g. with rollback).
Then you don't know many languages! Java, Python, and many others
provide robust, enterprise-grade logging facilities out of the box.
Haskell, Erlang, and many others provide all sorts of transactional
facilities, depending on exactly what you want, out of the box.
I'm familiar with Java and Python, and neither provide any sort
of transactional management, nor adequate logging for large
scale applications.
Or may not, if it is designed correctly. (This is one of the
rare cases where just dumping the memory image of certain
struct's might be appropriate.)
You're just making the cost/value proposition worse, not better.
That's even more code I have to write!
You have to write it anyway, since it's part of making the
application robust.
I've not followed the discussion completely, but most of what
I've seen seems to concern returning an error for the request
triggering the problem, and continuing to handle other requests.
No, that's not even how the discussion started. One of the major
advocates for handling OOM suggested this was not only possible, but
trivial.
Nothing in a large scale application is trivial, but handling
out of memory isn't more difficult than any number of other
things you have to do.
Unless the reason you've run out of memory is a memory leak,
you can.
Nope. All the other requests can die while you're trying to handle
the OOM condition. Or the other side could drop the request because
they got tired of waiting. The reality of the matter is that both
will happen.
The reality of the matter is that neither happens, if you
program correctly. I've written robust applications which
handled out of memory, and they worked.
The effort isn't that hard,
Yes, it is.
It's no harder than a lot of other things necessary to write
correct software.
It requires me to rewrite a considerable number of
language and sometimes even OS facilities, something you have admitted
yourself!
But so do logging, and transaction management, and a lot of
other things.
The entire reason I'm using a programming language is
because it provides useful facilities for me As a result, it isn't
the least bit unreasonable to conclude that rewriting language
facilities is hard. If I wanted to be doing to be writing language
facilities, then I'd just write my own damn programming language in
the first place!
But no languate has adequate logging facilities, nor transaction
management facilities, nor a lot of other things you need.
and it's a basic requirement for
some applications. If you don't handle OOM correctly, you're
application isn't correct.
Applications that require a response to OOM other than terminate are
an unsubstantial minority.
Finally something I can agree with. They're definitely a
minority. But they do exist. (I'd guess, on the whole, they
represent less than 10% of the applications I've worked on. But
it's hard to quantify, since a lot of lower level applications
I've worked on in the past didn't use dynamic memory, period.)
Systems that cannot permit termination as
an OOM response are almost certainly broken.
A system is broken if it doesn't meet its requirements.
I'm not sure either. But it is something that must be kept in
mind when you are writing an application which has to handle
OOM.
And it makes justifying handling OOM only harder, not easier! You're
making my case for me!
You're just ignoring the facts. Some applications (a minority)
have to handle OOM, at least in certain cases or configurations.
If they don't they're broken.
--
James Kanze