Re: helper threads layer

[Asko Kauppi <askok@...>]

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

-asko


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
> languages.
>
> > 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...
>
>
> --
> Javier