Re: bad alloc
On Aug 31, 6:33 pm, Adam Skutt <ask...@gmail.com> wrote:
Say that you want to save. If your file stream is already there, and
given that saving is logically a "const" operation,
It is not logically a "const" operation and never will be one. The
very notion is absurd. How can I/O be const?
Please note the word "logically". If you already have a stream and
data to save, saving itself __does not__ change program state.
Successful save might e.g. change the state of the "dirty" bit, if
there's one.
reason for things to go wrong (it's possible, but not likely). Or say
that you want to log the error. Logging is something that must a no-
throw operation, therefore, logging facilities are already there and
ready.
Providing logging as a no-throw operation is a logical impossibility
unless it is swallowing the errors for you. I/O can always fail,
period. Even when you reserve the descriptor and the buffer.
Moreover, it's generally impossible to detect failure without actually
performing the operation!
I know. Functionality that informs the operator about failures, like
logging functions, in a well-designed system, __are__ no-throw
operations. That might mean try{}catch(...){swallow;}. What else!?
That's why I said that I'd test inform_operator under load and __try__
to make it as resilient as possible.
Now, if functionality fails, and logging fails, tough. You think you
can do better? I think you can't. I think that terminating/restarting
the process might be a way out, but __only__ for some software and
some situations, and that percentage of those is smaller than what you
make it out to be.
I tried, a long time ago, to eat all my memory and then proceed to
disk I/O. This works on e.g. Unix and windows. Why wouldn't it?
Sure, if you're using read(2) and write(2) (or equivalents) and have
already allocated your buffers, then being out of memory won't require
any additional allocations on the part of your process. Of course,
performing I/O requires more effort than just the read and write
calls, and many (most?) people don't write code that uses such low-
level interfaces. Those interfaces frequently do not (e.g., C++
iostreams) make it easy or even possible to ensure that any given I/O
operation will not cause memory allocation to occur.
Nevermind that data is often stored in memory in a different format
from how it is stored on disk, converting between these formats often
requires allocating memory.
It might, but given the nature of e.g. logging, it is of course my
task to ensure these conversions are a no-throw (or better yet, actual
no-fail) operations. I believe that
1. conversions are rare
2. if they exist, it s the task of the logging to make it a no-throw
(or better yet, actual no-fail) operation. See how exception::what is
"const"? That's not by accident.
It's considerably smarter, and absurdly easier, to save off the file
before attempting the operation in the first place. This way, your
code can die in a clean fashion, and the user has a recovery file wit=
h
the changes up to the failed operation. Trying to create the recov=
ery
file under or after an OOM condition is very difficult. However,
trying to create the recovery file before the OOM condition is
trivial.
You can't be serious with this. I would really like to see a codebase
that saves state to disk prior to any allocation (any failure
condition, really).
You don't. You save it before performing the complicated image
processing operation that might fail, instead of trying to save the
file after it failed. Plenty of codebases expect you to do this, and
plenty of smart users do this automatically and out of habit, even if
the application does it for them.
That requires that code knows what is likely to fail. That's a pipe
dream at any given moment, and also not future-proof (random change in
the future, and another operation falls under "complicated image
processing that might fail"). Also, one of very tenets of e.g.
exceptions is to ease writing code when you don't know what will fail
(and, get this, you don't want to think about it).
Actually, what could be attempted is saving after any change. But that
won't work well for many-a-editor either. Best you can reasonably do
is to save recovery from time to time.
If that's the best I can do, then why the hell are you telling me to
handle OOM at all? You came up with the suggestion, and now you're
telling me what you originally suggested is not possible. So which is
it?
I was merely pointing that your line of reasoning is bad, it wasn't my
intention to bring OOM handling in the picture. Therefore, I will
abstain from any further comment here.
It's not unnecessary caching, it's transient peaks in memory usage
during some work.
What transient peaks? If the amount of memory allocated to my process
is less than what I actually need to perform my processing, it means
some sort of caching (e.g., pool or block allocator) must be
occurring. Writing those caches such that they support giving memory
back to the operating system may be difficult and not worth the effort
involved. In some cases, I may not even know they're occurring or be
able to influence them.
Erm...
web_response << "Welcome " some_person.diplay_name() << "!";
class person
{
string display_name() { if (culture == "en") return first_name +
last_name; ... };
};
I don't know how __you__ write your code, but I have transient peaks
all the time.
You often don't know how much memory a given system
has, nor you don't know what e.g. other processes are doing wrt memory
at a time you need more memory.
If the operating system's virtual memory allows for memory allocation
by other processes to cause allocation failure in my own, then
ultimately I may be forced to crash anyway. Many operating systems
kernel panic (i.e., stop completely) if they reach their commit limit
and have no way of raising the limit (e.g., adding swap automatically
or expanding an existing file). Talking about other processes when
all mainstream systems provide robust virtual memory systems is
tomfoolery.
But I have. I have been intentionally droving code up the wall with
memory usage and looked at what happens. If you have your resources
prepared up front, it's not hard doing something meaningful in that
handler (depends also what one considers reasonable).
Your definition of reasonable is asinine, since it requires
programmers to write code that relies on low-level operating system
behaviors and system calls. Moreover, it assumes that doing such
things is possible with any further exceptions occurring!
Erm... Given that system has plain C interface (no exceptions), and
given that writing is logically const (translates to "no exceptions"
in a sane codebase), this is a reasonable assumption.
Finally, it
assumes that the behavior of the system calls themselves is somehow
the only relevant thing!
Ultimately yes, it __is__ the only relevant thing, because this is
where the control of the code stops. What are you even trying to say
here? That code should react to e.g. a failure it knows nothing about?
Realistically, here's what I'd do for save case:
try
{
throw zone, lotsa work}
catch(const whatever& e)
{
inform_operator(e, ...); // nothrow zone
try { save(); } // throw zone
catch(const whatever& e)
{
inform_operator(e, ...); // nothrow zone
}
}
It is not possible to write 'inform_operation' generically in such a
way that it's nothrow unless it actively swallows exceptions. All of
the stuff that you said was 'Meh' is required to notify the operator!
Of course, assuming there is an operator is just icing on the cake.
Then, I would specifically test inform_operator under load and try to
make it reasonably resilient to it. But whatever happens, I would not
allow exception to escape out of it.
Doing this doesn't buy you a thing. It doesn't ensure the operator
(who doesn't exist) will see the message, it doesn't ensure you can
safely save. Ensuring these things requires doing what I suggest, at
a minimum, if it's even possible to do ensure notifications and
saving, which it is not.
If we're talking about an image processing program and saving, then
operator is kinda presumed. If we're talking about some daemon, then
the operator will see what has happened in the log when he gets wind
of problems.
Yeah, I agree that one cannot sensibly "handle" bad_alloc. It can
sensibly __report__ it though.
Reporting is handling and you're kidding yourself by trying to
distinguish them.
I disagree. For me, there's actually no such thing as "error
handling". There's error reporting and there's __program state
handling__ (in face of errors). This is IMO a very important
distinction.
Not when discussing out of memory conditions (and most exceptions),
there's not. It has no bearing on the relevant questions: will the
program terminate and how will it do it?
Even reporting may not be possible. Reporting
requires I/O, I/O requires memory and resources.
Most exceptions
occur because: 1) you're a bad programmer 2) you're out of some
resource (that you probably ran out of doing I/O anyway).
Hmmm... We are most likely in disagreement what are exceptions used
for.
Clearly, but your disagreement isn't really with me but with language
designers and implementers the world over.
I don't think so. Your thinking is pretty much that any exception
should lead to a termination. If that was thinking of language
designers, then a catch would be a no-return block, and if it weren't,
implementers would push designers to make it so. None of that is true
nor is happening.
Goran.