libeio, Windows

Tony Arcieri tony at
Tue Jun 3 07:47:42 CEST 2008

On Mon, Jun 2, 2008 at 11:09 PM, Marc Lehmann <schmorp at> 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

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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the libev mailing list