[...]
Timer.New() - returns userdata and assigns metatable. Use supplied lua_State?
timer:Start() - metatable function to start timer. Use supplied lua_State?
timer:_gc - metatable garbage collection. Use supplied lua_State?
timer->callback() - external call back into Lua
You used the word 'asynchronous' in your first email. I hope you're not trying to (for instance) call into the Lua interpreter from a signal handler or another thread, because that's going to royally mess up things and just end in tears😀. Lua is quite single-threaded by design.
The way I've used 'timers' is from an event loop, which calls select/poll (Posix) or WaitForMultipleEvents (Windows) or a variant to wait until an event happens or a timeout occurs, at which time you check for expired timers. When the Lua interpreter calls into the wait-for-event function you provide it will pass the correct lua_State pointer in. Typically you call this routine from the main coroutine, and the timer's callback will reactivate the coroutine that's waiting.
Once you get this mechanism going it's fairly easy to implement event-driven software, but your coroutines will still have to voluntarily give up control for all this to work.
My 'timers' were just elements in a priority queue.
Hope this helps some.
