lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 3/1/08, Javier Guerra <> wrote:
> On 3/1/08, Duck <> 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
> i'd second this idea.

Third. :-) I think Mike Pall's old event API proposal is a good start.
I was also doing some experiments with that prior to this thread,
using libevent on Unix and WaitForMultipleObjects on Windows.

It will be fine if we can at least agree on the way to notify a
cooperative scheduler that the current "thread" wants to wait on some
event, as this has to go through coroutine.yield...

Once we agree on the simple stuff (files, sockets, signals, timers) we
can move on to the fancier stuff as change notification APIs. :-)

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

On POSIX couldn't you at the worst case create a pipe and signal the
main thread by writing a status code to this pipe? This way the main
thread can just ask the system to notify when the pipe has data to be
read... maybe pthreads has a better way to do that, though.

On Windows the helper thread can create an event object and signal it
when it's done, and the event object is a handle that can be passed to

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

Once you have non-blocking IO you have non-blocking popen, so it is a
matter of making up a simple protocol to pass LuaSQL requests and
responses around.

> --
> Javier

Fabio Mascarenhas