[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: block-scope finalization
- From: Philipp Janda <siffiejoe@...>
- Date: Mon, 23 Nov 2015 10:52:10 +0100
Am 17.11.2015 um 17:50 schröbte Philipp Janda:
Am 17.11.2015 um 15:01 schröbte Viacheslav Usov:
On Mon, Nov 16, 2015 at 6:28 PM, Philipp Janda <firstname.lastname@example.org> wrote:
local t = transaction( function( a, b, c )
if c then c:destroy() end
if b then b:clear() end
if a then a:close() end
local a = t( f() )
local b = t( a:foo() )
local c = t( b:bar() )
-- do something with a, b, c
t:commit() -- or t:rollback(), or t:cleanup()
You can see the current state of my experiments here.
I'm currently trying to protect the rollback function (the one passed to
`transaction()` in the snippet above) from memory errors. I realize that
all bets are off if you allocate new Lua objects (strings, tables, table
fields, userdata, functions, ...), but even a simple function call could
allocate memory to grow the Lua stack, and thus raise an error. I
thought about using a separate coroutine for calling the rollback
function and `luaL_checkstack` to ensure a certain stack size. I can
also preallocate a certain number of `CallInfo` elements by calling a
helper function recursively multiple times in this coroutine and
yielding from the inner-most call.
Now my questions:
* Are there any other implicit memory allocations when running Lua code?
* Is there some way to protect the allocated `CallInfo` elements once
the recursive calls have returned, or do I have to disable the GC
* When is the GC triggered anyway? Only when new memory is allocated
(and by calls to `lua_gc()`)?
* Are there any other types of errors that non-faulty Lua code could throw?