lua-users home
lua-l archive

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

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 <siffiejoe@gmx.net> wrote:


What about:

     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
     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[1].

   [1]:  https://gist.github.com/siffiejoe/2c01b690bfdbc34b85a6
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 temporarily?
* 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?


TIA,
Philipp