Re: LuaSocket 3.0? (was Re: A proposal for faster userdata type checking)

["Javier Guerra" <javier@...>]

On 3/1/08, Duck <duck@roaming.ath.cx> 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
DB API.

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
finished.

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.

-- 
Javier