Re: LibEvent binding to Lua? Mix w/ HelperThreads?

[Doug Currie <doug.currie@...>]

Monday, April 3, 2006, 2:06:30 PM, Diego Nehab wrote:

> I am in fact talking about replacing the way Lua does I/O on Windows and
> on Unix, to make it work well with libevent on Unix and with IOCP on
> Windows. If that means I would have to eliminate FILE* usage from the
> Lua stdlib, I am fine with that. Probably no need to even touch Lua's C
> code. It can all be done with a plugin.

Yes, that is the approach I have used for my IOCP library.

> Why do you think this is too complicated?

I was reading too much into your "adapt Lua's file I/O functions and
LuaSocket functions to integrate well with this abstraction layer"
comment. Giving Lua the benefit of AIO in its existing I/O libraries
would mean integrating a scheduler into Lua. You don't seem to be
advocating that, but rather providing a library to support building
applications with AIO. That is much easier. The only drawback is that
a programmer can inadvertently use a non-AIO function, and block the
whole system. Perhaps that can be avoided with an AIO sandbox.

> As for mixing with HelperThreads, it is completely orthogonal to what I
> am suggesting. Although LuaSocket is not completely thread-safe, it can
> be made so with just a little work.

I see that HelperThreads can, e.g., take a Lua file handle (FILE *)
and use it in a non-blocking way using threads. This is something a
Windows IOCP library couldn't do.

I note that the libevent API is based on (fd and timeval) callbacks,
whereas IOCP is based on polling (GetQueuedCompletionStatus). I.e.,
the dispatcher is built outside library in my IOCP approach, whereas
it is inside the library in libevent. Which approach do you prefer?

e

-- 
Doug Currie
Londonderry, NH