[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: helper threads layer
- From: Javier Guerra <javier@...>
- Date: Thu, 9 Mar 2006 19:26:31 -0500
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...
Description: PGP signature