[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: need to convert C func -> closure within core (no stack usage, please..:)
- From: Asko Kauppi <asko.kauppi@...>
- Date: Tue, 15 Mar 2005 00:00:40 +0200
I will :) Got it working, only to realize the closure creation is
taking all the juice out of it.
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!
14.3.2005 kello 23:29, Mike Pall kirjoitti:
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
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...)
ideas from harder-than-hard core programmers welcome.
Why not create them once during initialization? Creating them at
for every metamethod access imposes a certain overhead (that will
ruin the performance possibly gained by creating a new core type). I
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
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.