RE: Memory Allocation Hooks

["Cory Bloyd" <cory.bloyd@...>]

In order to use the runtime hook to have different allocators for
different states, would you need to have a different C function
explicitly defined to call the different allocators?

I ask because our system does not use global allocation functions.
Instead it has allocator objects that get passed around.  In order to
allow different Lua states to use different allocator objects without
modifying the distributed code, I had to resort to a rather evil hack in
my override of the Lua allocation macros.

The override looks something like this

#define l_realloc(b,os,s) poLuaRealloc(L, b, os, s)

Where L happens to be the name of the Lua state that happens to always
be present when l_realloc() is called.

For the future, I respectfully request that a pointer to the Lua state
be made an official parameter to l_realloc() and related macros.  Or at
least, please don't screw up my hack :)  The OO-in-C design of the Lua
interpreter is wonderful.  It's a shame that it stops short of the
memory handling routines.

Our goal is to allow different subsystems to run independent Lua
interpreters in different threads.  Adding the OO-extension to the
memory macros allows us to do so without necessitating any thread
synchronization within the Lua system.  It lets us control and verify
the memory allocated to the interpreters independently.  It also allows
us to segregate memory fragmentation of the interpreters from each other
and the rest of the system.  For such a tiny change, it has been
extremely valuable to us and I think it would benefit others as well. 


-----Original Message-----
From: Jay Carlson [mailto:nop@nop.com] 

The three cases for the runtime hook (as opposed to a compile-time hook)

are:

1) You want different allocators for different states

...