Re: Using Lua's memory allocator

[Gavin Wraith <gavin@...>]

<91EDF0BE-E3EF-435E-BA45-99FF0F4A05FD@gmail.com> 
<64c1832052.wra1th@wra1th.plus.com> 
 <359981318341847@web102.yandex.ru>
In-Reply-To: <359981318341847@web102.yandex.ru>
X-Organization: Home
User-Agent: Messenger-Pro/1.00c (MsgServe/1.00a) (RISC-OS/5.16) POPstar/2.06-ds.5
Reply-To: lua-l@lists.lua.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

In message <359981318341847@web102.yandex.ru> you wrote:

> > If I grab some memory using lua_newuserdata, and after using that memory
> > for the above-mentioned operations simply throw away the pointer to it
> > (i.e. never push it on the Lua stack), then that memory will be reclaimed
> > - have I got that right?
> 
> First, to use automatic stack management, i.e. to have dedicated stack frame, 
> all your functions should be "Lua C functions" (see lua_CFunction) and be called 
> from Lua or using lua_call() etc. Big work here. Otherwise, you can only use 
> initial Lua stack, where *you* must lua_pop() chunks, because first frame never 
> returns. Not very useful too, better stay with malloc/free.
 
> Second, lua_newuserdata() creates and pushes(!) new userdata on stack. 
If you lua_pop() it, it may be immediately reclaimed.

Thanks. I had not thought of that. I do not think I dare go the route of freezing 
the gc temporarily, so I will take your advice and stick with calloc/free for 
intermediate values. It means some work disciminating the library's use of its 
memory allocations, to separate those which should use lua_newuserdata from those 
which should not.

> Anyway, leave internal allocations to malloc/free, and only allocate exported 
> objects with lua_newuserdata().
> Never store result of lua_touserdata() to permanent places, and you are fine.
> 
> [1] http://lua-users.org/lists/lua-l/2010-10/msg00246.html

Many thanks to all for taking the time to answer. Very useful for me.
-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/