lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Sam Roberts wrote:
> I've since come to the conclusion that malloc() NEVER fails on modern
> operating systems, so the code theoretically written to recover from
> failure never runs, and code that has never been run is not going to
> work when it is run.

On most common configurations of Linux (and probably other Unices as
well), this is true --- malloc() will always return you a valid pointer,
unless you run out of address space. The physical memory is only
allocated when the page is accessed for the first time. If the
allocation fails, you'll get an address exception.

This apparently vastly improves performance and memory usage, because
you only every need to allocate as much memory as a program actually
uses, rather than how much it says it uses. (As a side effect, it means
that your stack autoextends as it grows, which is very useful.) It does
make me rather nervous, though. There is an option to turn this off.

> Anyhow, what exactly would a lua program that caught an out of memory
> exception do? There isn't enough memory to run lua, so how is any lua
> code supposed to recover? Cleanup and get out are pretty much your
> only options.

Well, a system I worked with in the past dealt with this by keeping a
preconstructed 'out of memory' exception in the thread structure. This
meant that you could always throw one without needing to do any memory
allocation. When it got thrown, destructors would run, which would free
memory, which would allow the system to recover, etc. I don't believe it
ever actually happened in real life.

┌─── ───── ─────
│ ⍎'⎕',∊N⍴⊂S←'←⎕←(3=T)⋎M⋏2=T←⊃+/(V⌽"⊂M),(V⊝"M),(V,⌽V)⌽"(V,V←1⎺1)⊝"⊂M)'
│ --- Conway's Game Of Life, in one line of APL

Attachment: signature.asc
Description: OpenPGP digital signature