Re: Coroutines and blocking IO

[Jon Smirl <jonsmirl@...>]

On 1/26/06, Javier Guerra <javier@guerrag.com> wrote:
> but i feel that most of us wouldn't like to get a wrapping mechanism written
> in stone (in the language itself).  much like there's no fixed and standard
> OO system in Lua.  (of course, from time to time someone asks for one... but
> most of us just implement one when needed)
>
> what i'd like to see is the LuaSocket dispatch system extended a bit more, to
> make it very easy for other module writers to create non-blocking calls that
> cooperate with the dispatch.  that way, we would have a de-facto threading
> (and wrapping) system.
>
> also, i'd like to see non-blocking file IO (and database, and process
> spawning, and...) all pluggable into dispatch.lua

Writing a web server system like Kepler is going to force a some kind
of threadlike system. If you are servicing multiple requests you just
can't let one of the requests block everything for ten seconds while
it does a complicated database query. This is what happen in Ruby,
Ruby IO was synchronous too until they started doing web servers.

Instead of thinking of this as threading you could look at it as
requiring IO libraries to be written asynchronously.  In the old model
the library would implement a blocking read. In the new model you
implement read()=EAGAIN, call out to a registered callback if present,
epoll_wait(), get event, return. Now if there is no registered
callback this behaves just like a blocking read. Of course this system
need coordination in the C code since there is only one epoll_wait()
that is shared across all async IO.

Implementing threads isn't really needed, lua code in a loop can
always yield if it wants to. What you can't fix is a system call that
doesn't return for ten seconds.

--
Jon Smirl
jonsmirl@gmail.com