On Thu, Jun 05, 2008 at 02:56:12AM -0600, Tony Arcieri <[EMAIL PROTECTED]>
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
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
