lua-users home
lua-l archive

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



I will :) Got it working, only to realize the closure creation is taking all the juice out of it.

Tomorrow..

As to the explaining, yes, I have this working using userdata, and it can be done that way. Benchmarking is exactly what I'm doing, since userdata allocations are not so cool either. And core intrusion :) is the only way to avoid them. Now, after the core + closures, I'm at 0% optimized stage. Fun, hah!

-ak

14.3.2005 kello 23:29, Mike Pall kirjoitti:

 Hi,

Asko Kauppi wrote:
I'm modifying the 'luaT_gettmbyobj()' function within ltm.c (5.1w4) in
order to provide a couple of metamethod-like functions that are in fact
fixed within the core.

The problem is.. how exactly to do that?

I have the lua_CFunction pointers, of course, but creating a closure
without touching the stack (if I touch the stack, well, BOOOM...) Any
ideas from harder-than-hard core programmers welcome.

Why not create them once during initialization? Creating them at runtime for every metamethod access imposes a certain overhead (that will certainly ruin the performance possibly gained by creating a new core type). I hope
you realize that closures are heap allocated ...

- Add a Table * pointer in the global_State struct.
- Create a table when opening the universe and store it there.
- Create the closures and add them to the table (__index = ..., ...).
- Use the pointer from the global_State in the switch statement in
  luaT_gettmbyobj when your new core type is referenced.


But this bears the question: Why do you want to extend the core with
a new type? Is USERDATA or LIGHTUSERDATA not good enough for your purpose?
Did you benchmark this? Care to explain in more detail?

I ask, because maybe there is a problem behind it that might be better
solved with a (new) generic meta-mechanism. Or maybe not.

Bye,
     Mike