On Fri, Jun 09, 2006 at 06:29:37PM -0500, [EMAIL PROTECTED] said:
> if you take that view, then you can't use paging because the
> kernel might kill your process off on overcommit.
Or you should disable the overcommit (if possible).
> i'm not sure i understand how malloc failure can be a common
> enough event that it needs to be handled.
It is not only malloc failure, grep the plan9 libraries for sysfatal.
> i have never seen malloc failure on a production system where
> recovery was possible; i have seen some memory corruption that
> led to malloc failure, but there's no recovering from that.
>
> what is the senerio you're thinking of where malloc could fail
> and you can recover?
Let's say you have a fossil like file server and you cannot malloc memory to
process new requests. Do you want to flush the data buffers back to the disk
before you die, you you want to die in some library without any flushing.
Or you have a file server that keeps some non-file server related state in
memory. The unability to serve any more requests is fine as long as it can
start serving them at some point later when there is more memory. The dying
is not acceptible because the data kept in the memory is important.
Thanks,
Lucho
>
> - erik
>
> On Fri Jun 9 18:23:09 CDT 2006, [EMAIL PROTECTED] wrote:
> > There are cases when you want to leave the output of the program in
> > consistent state before you die (and you don't need extra memory to
> > achieve that consistency). Or even if the program cannot continue its
> > work, it would rather lurk around and wait for somebody to rescue it
> > instead of just dying. And in cases like that you just cannot use
> > libraries that call sysfatal.
> >
> > Thanks,
> > Lucho
