Re: Coroutines and blocking IO

[Glenn Maynard <glenn@...>]

On Thu, Jan 26, 2006 at 01:27:03PM -0500, Jon Smirl wrote:
> 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.

FWIW, I don't think this works with disk files on traditional Linux kernels;
select() always returns them, and I/O always blocks.  Blocking calls to
read a file typically wait more briefly, of course, but they do block,
resulting in unused time if no other threads are running.  If you're reading
from, say, a CD-ROM, seeks may cause much longer blocking.

You can do it with threads, of course (more expensive).  In Windows, you
can use the "overlapped I/O" API (request an I/O, completion becomes an
event).

-- 
Glenn Maynard