Re: [mildly OT] Some info about Python

[Sean Conner <sean@...>]

It was thus said that the Great Stefan once stated:
> 
> 
> Am 15.01.2020 um 23:35 schrieb Andre Leiradella:
> >
> >On 15/01/20 22:17, Stefan wrote:
> >>
> >>
> >>Well, that's exactly the problem with area allocators: What if your
> >>data no longer fits into your area?
> >You can create huge linear allocators. Bonus: if a bogus script exhausts 
> >the allocator, the script will end.
> >>Abusing virtual memory is extremely hacky.
> >
> >Not at all.
> >
> >Cheers,
> >
> >Andre
> 
> Well, it certainly is an interesting idea. But it has many drawbacks:
>  * It only works for one state at a time (if I get your approach right)

  I didn't get that impression at all.  lua_newstate() takes a allocation
function and a pointer to user data (it's luaL_newstate() that uses
malloc()/realloc()/free()).  It's simple enough to say, give 5M to each
state (or 50M or whatever limit you want).

>  * There will be a lot of dead memory (Lua uses realloc shrinking often)

  Andre did mention it was for short-lived scripts, and not for something
that runs for a long time (hours?  days?  For ever?)

>  * It assumes you have enough virtual memory (only x64)
>  * vm.overcommit_memory or equivalent must be enabled
>  * Users will complain about what top/Taks manager shows them
>  * Memory use has an hard upper limit now; or you need to check it for 
> every allocation

  It sounds like a hard upper limit.  And there's *always* a hard upper
limit, even with VM.  It's just that in most cases, you'll never hit it.

  I can see this method working for the right work case.

  -spc