On Sat, Nov 24, 2007 at 04:53:35PM +0100, Jochen Stenzel <[EMAIL PROTECTED]>
wrote:
> * I think it's great to have Windows support from the beginning, so
> programs using EV can be expected to be portable between UNIX and
> Windows, similar to the current version of Event.
It was a side effect of the portability requireemnts for libev :)
> * For the interface, I like the named parameters interface of Event.
> Of course this is a matter of taste (and performance), so this is
> just a personal note.
Oh, you can have the same interface, much higher portability (and slightly
reduced functionality) by using the AnyEvent module. That provides an
interface very similar to Event but transparently works on Glib, Tk,
Event, EV, Coro and even provides a portable perl event loop.
As you can see form the benchmarks, while AnyEvent is extremely slow
compred to native EV, it is still much faster than Event, and still
quite a bit faster than e.g. Glib, so efficiency should be of secondary
consideration.
> * I found that the timers are not restricted to full second
I will.
> * Speaking about the docs I find it a bit confusing to mix the
I will look into this.
> * The example provided for data() causes a warning (if run with
Oh right, I forgot to implement that (I don't use this kind of interface
myself :) Well spotted!
> * A signal watcher for the "INT" signal causes a Windows exception,
While some effort has been made to be able to catch (some) signals under
windows, microsoft claims that windows doesn't support signals, so I guess
the first step would be to make windows support it?
In any case, I canot really reproduce this with my activestate perl, so if
you know of a way to catch signals reliably on windows (according to msn
there isn't), then you should speak up and probably implement it :)
signals are a unix/posix thing, and while EV tries, of course this has to
be supported in the OS somehow.
> * An io watcher for STDIN does not work (in the mentioned Windows
> environment): terminal input does not reach the program, instead
> it is propagated to the command like processor after program
> termination.
Windows doesn't support this operation, select (both the perl one and the
windows one) works only on sockets. Since the select backend is used, and
libev happily uses perls select, you would have to first teach windows
about supporting select on the console:
Windows itself provides no alternative mechanism to do readyness
notifications (its I/O model if there were any, does not support
non-blocking operations, but is centered around asynchronous operations,
and the various WaitFor functions are not generic enough).
Either you use sockets, or you lose, and no event library can do anything
about it (this becomes more complicated as windows doesn't even support
the notion of a shared handle space, such as fds, so the fact that perl
provides fileno and other unix-stuff on windows cannot hide the fact that
this is part of a unix emulation, and it breaks down here and in many
other places).
Also, ignoring the fact that libev is also a C library, in case of EV, it
has to handle perl fds. And it does handle perl fds just like perl, which
IMHO is the right thing to do. Perl fds are not neccssarily a concept
known to windows (at best perl uses the msvcrt).
If you need good posix support, you have to use a posix operating system,
or an emulation layer like cygwin, where select actually works on stdin.
> * The STDIN io watcher causes a very high load (100%).
Your callback doesn't check for errors (if windows provides any you will
get an revents with EV::ERROR set). libev tries to detect bad fds, but
this hasn't been tested very well on windows, either. In any case, EV
cannot do what the operating system itself does not support (or, in this
case, perl, as that is what is being used).
But this is probably OK, I cannot imagine anybody trying to do serious
development under windows, especially not with the half-baked unix
emulation perl provides. It simply doesn't work well to force one model
that works everywhere else onto windows where it doesn't. EV shares the
same limitations as perl and other programs suffer from, and there is
little one can do.
EV actually should work for sockets, the only part of windows where the
event model maps onto the EV/Event etc. model. Thats the only part that
can reasonably work.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
