lua-users home
lua-l archive

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

Not reading the whole message thread (sorry), but LuaX code has a working inter-thread messaging code (no dependencies) which was needed to get SDL_Mixer callbacks running (to Lua). They are called for pre/postprocessing of any sample blocks being played, but the call comes from a separate thread.

It consists of a data queue (FIFO), adding stuff in C side, and removal (by polling) in the Lua side.

Not sure this helps, but at least it shows there is a need for such a feature. Sometimes. :)

btw, the efficiency of running a music, and letting Lua code show its waveform on the screen is rather Good! :D


Javier Guerra kirjoitti 10.3.2006 kello 2.26:

On Thursday 09 March 2006 7:00 pm, Adrian Sietsma wrote:
Javier Guerra wrote:
hi everybody

finally, i think i have it working! it's a library of helper threads,
meant to make it easy to write nonblocking libraries in C.

I have implemented a pure lua version of an event iterator based on Mike
Pall / Diego Nehab model of 2004.
It is working, but i'm still tinkering with parameter order etc.

amazing; i read the model proposal and found it very compelling, but too much extensive. and (for me) the weak point is how to create new libraries that
would work nicely with the event framework.

so, i proposed a different approach: make it easy to write nonblocking
libraries with a regular API, so that a pure Lua dispatcher would be much
easier to write.

mostly, i wanted to keep with the primitives/mechanisms separation. i think the dispatcher should be an application specific mechanism, but to make it easy, it was needed a new primitive. i think it's called a 'future' in other

I personally am hooked on the idea of 2 seperate layers - one to provide
events / event notifications, and ont to despatch event handlers.

i first tinkered with LuaThreads, but it seems that everything is far easier and there's less resource contention if the background threads can't touch
the Lua State.

i'm trying to keep the dispatcher design out of my library, so that you could
choose between any number of threading styles: one-per-tasktype,
one-per-user, worker-pool, etc.

How do we go about stimulating discussion / idea swapping in this area ?
This list ? A new wiki page ?

as long as nobody objects, i'd suggest staying on this list...