Re: bad alloc
On Aug 31, 5:33 pm, Adam Skutt <ask...@gmail.com> wrote:
On Aug 31, 9:36 am, Goran <goran.pu...@gmail.com> wrote:
[...]
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!
If you can't write your output, then logging will fail. But
that's a different problem from running out of memory.
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.
It's very simple to ensure that a write to an ostream doesn't do
any allocations, if you design your streambuf correctly.
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.
Yes, but if you're logging an out of memory condition, you don't
need any of those conversions (or you know which ones you need,
and you can use static or pre-allocated memory for them).
If you truly believe the fact that
read(2) and write(2) do no allocations is somehow relevant in this
discussion, then you are truly clueless.
Either that, or he knows how to implement robust logging.
Although most applications don't need it, I have worked on one
or two where we had to return an "insufficient resources" error
on OOM, and continue handling further requests. The most
difficult problem was ensuring that the OOM didn't cause a stack
overflow (this was on a single threaded Unix system), and not
logging the error or handling further requests.
[...]
It's not unnecessary caching, it's transient peaks in memory usage
during some work.
What transient peaks?
Those due to handling a specific request. One obvious example
is parsing filters in LDAP; the filter can contain an
arbitrarily complex expression, which must be represented in
memory. If you run out of memory to represent it, you abort the
request (freeing the memory) with an "insufficient resources"
error. That doesn't mean that you can't handle more reasonable
requests.
[...]
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.
All mainstream systems except Linux (and I think Windows, and
some versions of AIX, and I think some versions of HP/UX as
well), you mean. The default configuration of Linux will start
killing random processes when memory gets tight (rather than
returning an error from the system request for memory).
--
James Kanze