On Mon, Jun 02, 2008 at 10:52:36PM -0600, Tony Arcieri <[EMAIL PROTECTED]>
wrote:
> First let me say: I've really been meaning to check out libeio.
I hope you are aware that this thread was about libev, not libeio :)
I don't think any of what I wrote can easily be applied to libeio, except
what you quoted:
> > It's a completely, utterly, broken platform.
... in a very general sense :)
> Not that I have any real interest from a practical perspective, but have you
> considered trying to map Win32 I/O completion ports to libeio?
No, this isn't the problem. Using I/O completion ports is close to
trivial, and would be completely optional - using threads works fine on
windows as well.
the problem is that most of the functionality just isn't there:
- no stat, no readdir (those could be emulated with some loss of fidelity)
- no chmod etc. (completely different model)
- no symlinks (not even close to being able to emulate these in a sensible
way)
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.
The best way to approach this is to use a library thta emulates all this for
you already, e.g. cygwin (there are others).
With libev, the issues are limited (only sockets work, and little else can
be made to work) to make it useful on windows as-is. (for me at least).
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 seems like the only option for I/O on Windows that doesn't completely
> and thoroughly suck.
Absolutely. But it doesn't do I/O readyness notifications, so is not
an option for libev for example (one could probably hack around it by
requirign windows XP+ or something like that, though, which supports some
undocumented hacks).
For libeio, using pthreads on windows and making it work in a less efficient
but working way is trivial, *iff* you have emulation of the missing
functionality.
So... the solution for libeio is clearly to use an emulation layer.
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.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.
> I've received quite a few requests for supporting Rev on Windows, and at
> this point I don't even want to bother... right now I'm just hoping someone
> will do the work for me and release a patch.
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.
If ruby uses operating system handles and not file descriptors, then you'd
need a nasty translation layer between those two.
It might be possible to extent libev to offer such a translation layer
(you basically need an array, and either an hashtable, a fast cpu or some
hacks), but right now, libev guarantees a comaptible interface on windows and
unix, which means file descriptors on both.
> That said, I assume I can use libeio alongside libev? There's certain
> things I don't believe I can do on top of a Proactor (SSL, for example)
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
>
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
