[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LibEvent binding to Lua? Mix w/ HelperThreads?
- From: Javier Guerra <javier@...>
- Date: Tue, 4 Apr 2006 09:37:36 -0500
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:
pgppJ6N5ZS77A.pgp
Description: PGP signature