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

[Javier Guerra <javier@...>]

On Tuesday 04 April 2006 9:29 am, Doug Currie wrote:
> >> 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.
> >
> > Right, but if a thread blocks on a call that chooses never to return,
> > the thread is dead, right?
>
> I have been assuming that for AIO there are no threads, only
> coroutines. A major benefit of AIO is that, if the library is designed
> properly, nothing waits, and no threads are needed. A coroutine
> scheduler at the Lua level can handle everything.

here Diego points to a potential drawback of HelperThreads.  Of course, that 
could be counted out as a bug in the library code.  Also, there could be a 
thread:kill() method. since the 'dead' thread isn't the one running Lua code, 
it could be called by the scheduler if any task spends too much time in the 
"Busy" state.

> Typically, one instantiates a bunch of coroutines. Each coroutine uses
> AIO calls to perform I/O. The coroutine is suspended while the I/O is
> pending. The scheduler polls, and when it receives an I/O completion
> it resumes the waiting coroutine. This way, each coroutine can be
> written as a simple serial process. An accept() coroutine may spawn
> other helper/client coroutines that operate similarly.

that's exactly how the 'sample' scheduler in HelperThreads work.  the only 
difference is that those 'AIO' calls are written with usual blocking IO calls 
on a different OS thread (this is the 'helper thread').  This makes life 
easier for library writers, while complying with a simple Lua 'AIO-like' API.


-- 
Javier

Attachment: pgprX2y6DCTN9.pgp
Description: PGP signature