[snips]
The OS ought to tell a process how much memory it can "reasonably" have.
Sounds good. I'm currently running 148 processes, ranging from mixers to
window managers to browsers to multiple DB servers. If a DB server needs,
oh, 256MB to process a large query, is that reasonable? How does the OS
decide?
It is very bad design to allow something to gobble up huge portions of
swap space, slowing every other part of the system to a crawl, except in
the relatively unusual circumstnaces where the process does genuinely
need all of the systems' resources.
It's a bad design to have the current process suck up swap at all,
generally, as the usually appropriate solution is to swap low-usage
or low-priority processes rather than active ones, thus freeing the memory
to be used by the process actually doing things.
So the strategy of asking malloc() for memory until failure ought to be
the best one.
Yet it almost never is, as even between one malloc and the next, the state
of the system can change significantly.
The reality is that it is not. Most systems will happily
hand out memory that cannot be afforded, and is almost certainly isn't
really wanted, allowing exploiters to tie up system resources. However
there isn't an easy answer, which is why we having this sub-thread.
There is an easy solution: use single-process operating systems.
readline() doesn't provide the answer either. It doesn't try.
It doesn't even try to be useful - discarding perfectly useful data, for
example.
It
provides something that is good enough for casual use
Actually, it doesn't. It provides something which serves best as a guide
of what not to do with an input routine.
reader into the way of writing functions. If he can improve on
readline() then the chapter has done its job.
If he can improve it, he's obviously doing better than the author is...
and if he can, he probably doesn't need readline in the first place.
one. For instance a function that writes an error message to stderr, and
then terminates, might be exactly what is wanted in the context of a
particular program, though it is no good for a general-purpose fucntion.
A function which gracefully handles errors - out of memory, end of file,
whatever - and returns a status indicating what's going on, rather than
just deciding "Hah, your data doesn't matter, so I'm going to discard it"
would be better still - and would be useful as a GP function. It'd also
make good fodder for an algorithms book, as in "Here's how to develop a
sensible algorithm to handle input."
Too bad we don't have someone interested in writing algorithm books - and
competent to do so.
