Re: memory management: lua_Alloc and handling exceptions

[nobody <nobody+lua-list@...>]

On 16/05/2020 14.49, Massimo Sala wrote:
> 1) Concurrency
>
> Our software can instantiate many instances via lua_newstate()
> Each state shares the same allocator routine.
> Each one has its own private struc.
>
> Does Lua call the allocator with some sort of synchronization,
> or should I protect the accesses to the struct (read and write) ?

If each instance has its own private struct, there's no sharing and
hence no synchronization necessary.  If you introduced some form of
sharing, you will probably need to protect that.  (By default, there is
none – i.e. if any one lua_State is only ever used by a single thread,
you can have arbitrarily many running in parallel and all is fine.)

> Should I add a /lua_State *L/ to tMemoryAccounting ?

If you need a reference to the Lua state (why would you? O.o), you will
need to keep that yourself inside the `*ud`.  (And your allocator will
have to be able to work without it.)

> Am I missing a lua_get_current_state(void) ?

There is no "current state", all states are fully independent and any
calls that you make identify what state to work on by passing it as the
initial `L` argument.

> 2) handling exceptions in the allocator

Your allocator only deals with memory management and cannot interface
with Lua beyond that.  So there's no extra exceptions or anything like that.

> For example: we can decide, at a certain moment, the allocator have
> to fail allocations above 1 Mb. For stress-testing purposes, or for
> other reasons. > If so, the Lua routines should return an error to our software,
> which ends gracefully.
All you can do is return NULL, which *might* result in Lua producing an
out-of-memory error.  (First, it'll do an emergency garbage collection
and retry, and then maybe it works and the rest of the program won't
really notice.  Only if that fails, the allocation actually fails, and
then that error may or may not (but probably will at that point) bubble
upwards.)

(The Lua tests include a custom allocator that limits memory, you can
look there for an example if you want.)

> My requirement is: letting Lua fails the current API with the error 
> LUA_ERRMEM.
This *might* eventually be the result, but there's no way to force that.

> If I understand correctly: > - the allocator cannot call luaD_throw, because it calls atpanic and
> aborts the program; > - cannot use setjmp: jumping out of the allocator, all the cleanup
> code of Lua current routine (destructors, stack, etc..) is skipped. > The problem can be split in two sub-problems:> - how can the 
allocator set the Lua error state?> - how can the allocator stop Lua's 
current routine processing and
> return to the caller?
The allocator is not a function living in "Lua land", it exists outside
and cannot do any of these things.  (Part of the reason is that the
allocator is already used while the Lua state is being constructed, and
at that point all of these facilities provided by the Lua state do not
exist yet.  That's also part of the reason why the allocator has no
pointer to the Lua state – it may not yet exist.)

> For requests of new allocations / realloc, the allocator can return
> NULL and set, for example   L->status = LUA_ERRMEM;    ?
L->status is a "Lua land" concept and not part of the allocator
protocol.  Lua will not check what you put there and will overwrite it
with its own value.

> (also free because it checks for possible corruptions of the memory 
> pointers).

Free cannot fail (or at least it can't signal errors).  If you want to
abort, you'll have to do so by other means (e.g. abort()?)

-- nobody
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org