tony at medioh.com
Thu Jun 5 10:56:12 CEST 2008
On Thu, Jun 5, 2008 at 2:38 AM, Marc Lehmann <schmorp at schmorp.de> wrote:
> Yes, but neither does libev or any event-library support that
> completely. It is simply unreasonable to expect a single mechanism to work
> with every type of hardware, software and protocol.
Exactly, and for that reason Proactor always seems to compliment Reactor, as
Proactor fits most cases but Reactor provides the catch-all.
> 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.
> Even the attempt to apply a single mechanism to e.g. both sockets and
> files is simply bad and broken design, independent of any "patterns".
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 said, Proactor generally wraps up writes with a non-blocking, buffering
write call. Better implementations of Proactor (among which I'd consider
Rev to be one) fire off an event for write completions. The inversion of
control caused by this model tends to be a cause of some confusion,
particularly with writes, but it can be wrapped up in ways that eliminate
problems with automatic write buffering, such as the Actor model.
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.
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
That's the model that best benefits systems based on communicating
sequential processes as the message carries both an event notification and
resulting state. It removes programmers from both event monitoring and the
underlying I/O, and frees them to handle I/O events solely in the form of
message processing, which in the end is what it's really about.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the libev