[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaSocket 3.0? (was Re: A proposal for faster userdata type checking)
- From: "Javier Guerra" <javier@...>
- Date: Sat, 1 Mar 2008 20:58:21 -0500
On 3/1/08, Duck <email@example.com> wrote:
> Incidentally, it sounds as though what you are building isn't really
> LuaSocket 3, but LuaAsynCore 1, so it seems as though there is a case for
> naming it as a new library, and keeping LuaSocket 2 as an alternative, and
> more traditional, socket-specific API for those Lua users to whom it's
> sufficient, more comformatable, etc. In other words, reflect the
> difference in nomenclature as well as implementation.
i'd second this idea.
as an anecdote, some time ago, i tried to develop a similar
infrastructure, to have all kinds of I/O under one single
event/queue/select/whatever. searching for event-driven libraries,
some were quite flexible, but in the end required the I/O to signal
availability on a file or file-like object. that clearly left out any
the only solution i could think of was using helper threads, that is,
create a thread that blocks and signals the main one when the task was
and that's the story behind Helper Threads Toolkit. unfortunately,
the two requirements that stem from this approach (new I/O libraries
and pthreads) has made it totally uninteresting for almost everybody.
so, if the new LuaSocket (or LuaAsynCore :-) can handle any file-like
object, it could be a great foundation for all kind of servers.
now the next challenge would be to create a split SQL library, to
isolate the blocking API in a second process, using IPC to expose a
non-blocking SQL API.