[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LibEvent binding to Lua? Mix w/ HelperThreads?
- From: Javier Guerra <javier@...>
- Date: Fri, 31 Mar 2006 06:59:01 -0500
On Friday 31 March 2006 2:00 am, Diego Nehab wrote:
> > Just wondering, how does a LibEvent binding into Lua sound? Right now
> > it seems to be a good option/addition to the HelperThreads library for
> > my MoonLog application (syslog/metalog replacement).
> It would be nice to come up with something that worked both on Windowses
> and Unixes. Anyone has experience with libevent on Windows? Does it work
> only for sockets?
i'd also like if somebody with windows experience would help porting
HelperThreads... i guess your pt.c layer would be a good start, but i don't
have a windows development system to test it.
> Also, it would be good if whateve solution we come up with worked with
> coroutine-based dispatchers where threads are not available.
i've been thinking on this, in fact, trying to do it all at once was a major
stumbling block for my two or three initial versions of HTT.
but, once the main (thread based) API is somewhat stable, and (hopefully)
accepted; it wouldn't be too hard to add a polling API, where the (*work)()
callback is called repeatedly until it's done, maybe even setting some fd and
telling HTT "don't bother calling me until this fd is writeable/readable"
when that's done, a simple compile flag might disable the threading API and
making the whole thing usable on non-threading environments.
with all this on place, any library writer would be able to choose between
ease to write (threads), or wider compatibility (poll). i guess that most
libraries for 'big' (linux,windows) systems would tend to use threads, and
those that hope to be usable on 'small' (embedded) systems would try to do it
Description: PGP signature