 |
lua-l archive |
|
|
||
|
You will find discussion on this in the archives, if only you dig deep enough. (sorry, no link here)
Helper Threads was already mentioned. Also other Lua threading kits each solve this in their own way (with own pros and cons).
My code, Lua Lanes, is an addon library so it requires no patching to Lua itself. You'd bring up one "lane" (separate Lua state, and OS thread) that would take in the callbacks and forward them to Lindas, which are inter-state coordinated data moving vehicles. Think of them as shared tables (with FIFO behaviour if required).
Yet another approach, which I have taken years back with SDL audio callbacks, was to craft my own C-side data structures that would be filled with the callbacks and emptied by a poll from Lua. There the issue becomes how general purpose you want it to be. If only a flow of numbers, even this should do.
It might fit the Alien usage model, but personally I don't like that level of binding, personally.
-asko Cosmin Apreutesei kirjoitti 5.8.2009 kello 18:36:
Hi, I have a library in which I can register asynchronous callbacks. Problem is, I can't call Lua inside the callback because the state is not consistent (obviously). Is there any way I can handle the lua state in consistent steps so I can enter back to lua and call a lua function? Python has this signal lib[1] that seems to work this way, executing the callbacks just between "atomic" python instructions. Sorry if this is old potatoes, I'm reading the list as fast as I can :) Another solution would be to keep the callbacks into FIFO list and have lua pull them from there -- and let the user solve the threading problem separately, with a threading library or with coroutines, depending on the design of the app. I was thinking of adding this functionality to alien as a general solution for async. callbacks. Is that a generally useful pattern to belong to a binding library or just my special needs? [1] http://docs.python.org/library/signal.html