Re: Asynchronous HTTPS in Lua

[William Ahern <william@...>]

On Wed, Aug 28, 2013 at 04:01:32PM +1000, Ross Bencina wrote:
> On 28/08/2013 3:06 PM, William Ahern wrote:
> >My goal is to show the Node.js and Twisted crowd how it should really be
> >done ;)
> 
> Hi William,
> 
> From reading your site I notice you don't think Windows IOCP is 
> supportable.
> 
> Given that you mention Node.js, and seeing as libuv (used by luvit) was 
> specifically developed for Node.js to work accross the Unices and 
> Windows IOCP), could you explain what you see as the disadvantage of the 
> libuv approach? It seems to me IOCP is a cleaner model, but I don't 
> really know the advantages (if any) of the other approache(s).

One of the biggest features of cqueues from my perspective is that it
doesn't depend on any specific kind of event loop, and can be integrated
into various applications without conflicting with their I/O model. cqueues
is a module (or set of modules) and its asychronous I/O framework doesn't
leak into the wider application. It's middleware.

For example, an entire cqueues-using application or library could easily be
used from Nginx, without using the Nginx asychronous I/O API, by simply
registering the top-level cqueues file descriptor with Nginx's event loop.
You could also use cqueues from luavit, or similar frameworks. It's
framework and application portable. It can only do this because of the way
epoll, kqueue, and similar kernel facilities work, whereby you can use a
single file descriptor as a signaling proxy for an unlimited number of other
descriptors.

So, cqueues isn't trying to be another libevent, luavit, or COPAS. In fact,
the biggest project I use cqueuesin is a large C daemon which I recently
added Lua scripting to. The entire scripting environment ties into libevent
at a single point. If I wanted to, I could move the entire environment into
another system, using a different event loop or polling system, with minimal
effort.

IOCP cannot do this--it's not software-composable in the way as traditional
Unix readiness signaling. It's broken in the same way that POSIX threads are
broken. With POSIX threads you can't poll a thread mutex, which means that
combing threaded and asynchronous libraries and modules is very painful and
complicated.

For Windows I've been contemplating a hack--instead of a cqueue object
exporting a file descriptor, it exports a descriptor set a la select(2). It
won't be as scalable as epoll/kqueue, or IOCP, and it'll be a little clunky,
but at least it would allow basic cqueues using applications to work on
Windows.