Re: Luasocket: poll vs select

[William Ahern <william@...>]

On Tue, Feb 21, 2012 at 02:27:02PM -0500, Javier Guerra Giraldez wrote:
> On Tue, Feb 21, 2012 at 11:54 AM, Graham Wakefield
> <wakefield@mat.ucsb.edu> wrote:
> > Luvit is very cool, but a standard lua module binding of libuv would also be very great.
> 
> +1
> 
> there are also some bindings to other event libraries (libevent, libev, etc)

I have a module which schedules coroutines using kqueue()/epoll().

There's no single main loop. Rather you create objects which wrap a kqueue
or epoll descriptor, and attach coroutines with :attach or :wrap. You then
call :step to process events. Depending on the timeout parameter, :step can
block or not, similar to poll/select.

To effect a poll the coroutine should yield one or more event objects.
Construction of an event object is implicit when calling cqueues.poll(),
which calls :pollfd, :events(), and :timeout() on the passed object(s), and
creates a registry anchor so that the descriptor doesn't get closed, which
would corrupt the kqueue/epoll state. (It's also required that objects don't
close internal descriptors--which have been communucated via :pollfd--before
being garbage collected.)

In this way you can stack them, so that a cqueue (i.e. continuation queue)
can yield in a coroutine which is being scheduled by another cqueue. This
also means the module can play well with LuaSocket or anything else, because
you can use LuaSocket to poll on the kqueue or epoll descriptor of a cqueue.
I also have plans for an nginx module, so that you're limited to only using
nginx's exported I/O facilities.

It's entirely self-contained in other respects, too. The only "gotcha" is
that it requires Linux or a *BSD, and Lua 5.2. There are no other external
dependencies in Lua or C. Not event libevent or libev, which are entirely
superfluous anyhow when explicitly relying on kqueue or epoll capabilities.

The module also includes a DNS library (both stub and recursive modes), a
sockets library (with SSL), and a file-change notification library (using
inotify on Linux and vnode kevent filters for *BSD).

If there's sufficient interest here I can open source it.

There are currently no callbacks because I figure most people set a callback
to resume a thread, and both closures and Lua threads are roughly similar in
size, although with a callback interface most people are creating new
closures constantly, whereas with coroutines there's less churn. Adding a
callback interface is on the todo list, in any event, and relatively
trivial.