On Thu, Jun 5, 2008 at 2:38 AM, Marc Lehmann <[EMAIL PROTECTED]> 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. -- Tony Arcieri medioh.com
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
