On Mon, Jun 2, 2008 at 11:09 PM, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> libeio really is meant to make your whole program asynchronous, if you > "just" > want async file reads and writes, aio_read/write might be the better > interface. > I'm really looking for something that acts as a scheduler. Rev, for example, hijacks the role of the normal Ruby scheduler and installs libev in its place (at least in Ruby 1.8, which is green threaded). What would be ideal is libev as the core scheduler, providing readiness notifications where they're explicitly needed, and libeio handling asynchronous I/O. (Let's forget Windows here for a moment) One of the projects where that sort of approach would be ideal is the Rubinius virtual machine, which already uses libev as its core scheduler. Rubinius exposes a "Scheduler" object, and one of the things you can ask the Scheduler to do is perform an I/O operation for you. You give the Scheduler a Channel (i.e. message port) to receive the event completion message on, then call the receive method on the Channel object, which puts the current task to sleep until it receives a message (letting other tasks run). When the I/O operation completes, the Scheduler wakes the task back up by sending it an Event object with the requested data. Seems like a pretty good use case for libeio... The best way to approach this is to use a library thta emulates all this for > you already, e.g. cygwin (there are others). > What about MinGW? That's what the Ruby people on Windows seem to be using nowdays, as Ruby incorporates a lot of the POSIX semantics into the core language. But for libeio, I see no hope of ever making a sensible windows port without > something like cygwin - too much is simply missing or totally different. > > [...] > > ...it doesn't do I/O readyness notifications, so is not > an option for libev for example In most of the use cases I'm intended, I'd really need both. Certain libraries (namely OpenSSL) wrap up their functionality in such a way that you *must* let the library do the I/O due to the nature of its API, and in those cases I'd still need something like libev to give me readiness notifications. In all other cases, I think it's best for the underlying library to perform the I/O for me. > And for libev, the solution is to realise that libev's model (the posix > model) simply doesn't map on windows (its not just that the functions are > missing or named differently - they have different and often incompatible > semantics as well). > I think there's a pretty limited problem domain that actually requires readiness notifications vs. async I/O. That problem domain is pretty much limited to OpenSSL. I really can't think of any other cases offhand... I.e. if you want to be efficient on windows, you cannot use libev, because > the *API* cannot be mapped efficiently onto windows. So while one could > improve libev a bit, using it means using the wrong model on windows. > > Or in other words: you cannot share code that is efficient on windows and > the rest of the world. Microsoft deliberately and deeply was designed to > be incompatible with anything else. > Yeah, that's pretty Machiavellian of them. It sounds like while it'd be possible to expose the same API as libeio and libev (with libev being comparatively broken), the internal implementation would be considerably different versus other platforms, and hence the semantics. Perhaps you could expose just the libeio API on Windows, and concede that anyone who needs readiness notifications is screwed? If you limit yourself to sockets, this shouldn't be such a big problem. I > don't know how ruby deals with sockets on windows - perl squeezes them > into file descriptors just like everything else, so using libev on windows > + perl is close to trivial. > Yes, that's what Ruby does as well... You should be, it does not, however, have any specific interface for libev > yet (it should work with any event library, and even without one), and > documentation is clearly lacking. > > I might also do much more > Rubinius's scheduler gives you the option of either receiving an event notification for I/O readiness or having the scheduler perform the I/O for you. In order to replace the latter with libeio I'd still need hooks into libev for the readiness notifications. So really I'd need to use both alongside each other... Well, C++ is fully compatrible with C libraries. What kind of functionality > would you like to have? Would you want to be able to specify objects > and methods instead of a callback and a data pointer? Yes, that'd be wonderful. -- Tony Arcieri medioh.com
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
