[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: hooks & coroutines
- From: Andy Sloane <andy@...>
- Date: Sat, 29 May 2004 10:59:22 -0500
Mike,
Thanks for your feedback!
On Sat, May 29, 2004 at 03:42:02PM +0200, Mike Pall wrote:
> However I'm not sure if this is the best solution. Debuggers and Profilers
> need to be aware of thread creation anyway. So I suggest to add
> LUA_HOOKTHREAD and call it from luaE_newthread() and luaE_freethread()
> (with the just-created or the to-be-deleted lua_State). You can then
> add the hooks to the new thread or clean up your own state.
Agreed, this is a much better solution. I didn't really want to change
Lua itself just to inherit hooks, since it seems like a useful feature.
If you want to write the patch, at least one person will eagerly use it.
> Note that your job is going to get easier with Lua 5.1 since the allocation
> callback is part of global_State (but the member is unfortunately called
> 'realloc' -- this is a potential name clash and asking for trouble.
> Umm ... Roberto?). But we would need lua_setallocf() in addition to
> lua_getallocf().
Ah, interesting. Well, it's the line/call/return hooks I was interested
in -- the way it works is during each allocation/free, it just makes a
note in an internal queue, and then when the line hook is called, it
dumps the queue and attributes the allocations and garbage to the
previous line of code.
But being able to set the allocation callback without overriding
l_realloc and l_free with #defines would be very nice indeed.
What would also be very nice is some clean way to know the difference
between allocating memory for the stack and for the heap, but I can't
see this as being important in any other context.
> BTW: Is there a package that collects all known profiling, tracing and
> coverage tools?
I doubt it, but certainly I'm interested too.
-Andy