libeio, Windows

Marc Lehmann schmorp at schmorp.de
Thu Jun 5 16:45:48 CEST 2008


On Thu, Jun 05, 2008 at 02:56:12AM -0600, Tony Arcieri <tony at medioh.com> wrote:
> > Ultimately, it is the job of the application to chose the correct
> > mechanism, a good library will offer both and lets the app select the most
> > appropriate interface.
> 
> My main intended use case for libeio (in Rubinius) certainly implements
> both: you can either have its Scheduler perform I/O or give you readiness
> notifications.  It's your choice!  Generally the former is the way to go...
> but if you really need it the latter is available.

I am sorry, but we must be talking past each other. libeio cannot give you
readyness notifications, and using it for I/O on sockets is simply broken
design.

As long as you use libev _internally_ and then do synchronous I/O
_internally_ for sockets then thats fine, but no libeio is involved here
at all. If you use libeio internally for files (for example), thats fine,
too.

But doing I/O for sockets is generally wrong because it unneecssarily pins
down resources for an indefinite amount of time, even when they will never
be needed.

> Proactor fits an alternative form of asynchronous I/O which generally falls
> in line with the nonblocking I/O / readiness notification model.  The bottom
> line is that in the typical event-driven non-blocking framework, you don't
> actually care about the notification at all.  You just care about the data.
>  The notification means data is ready to send or receive, and the backend
> framework should deal with that, rather than the application programmer
> having to deal with I/O readiness events then perform the I/O itself.

That's fine, but you keep bringing in libeio into the discussion, which is
an implementation detail. and using libeio for sockets is plain wrong.

> Actors give programmers the choice of asynchronous or synchronous I/O and
> let the programmer mix the two freely without repercussions.  It's the best
> of both worlds.  But underneath, the I/O model needs to be fully
> asynchronous for it to work.

That doesn't make sense to me - synchronous I/O is *the right thing* for
sockets (on posix systems). It's the most efficient way to handle sockets.

> I don't suppose you'd consider this intermediate model (one that works with
> sockets, or ttys, or whatever): do as much I/O as the programmer requests...
> less but not more, so long as less is more than nothing, and notify the
> programmer when the request completes

I think abstracting I/O can be very useful - the issue I have is bringing in
libeio all the time, which is a red herring, because its not a solution to
the problem, it makes sense for some cases (as implementation) and sense for
others.

The same is true for the libeio API: it doesn't make sense for sockets.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list