Hi Marc,
thank you for your long and detailed answer. Unfortunately I am in a
hurry these days, so sorry for the delay.
>> * 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.
Ok, I wasn't aware of this specific fact, thank you for the hint.
>> * Speaking about the docs [...]
>
> I will look into this.
Thanks a lot, I had a look at the docs in version 1.5 and could follow
the structure much easier.
>> * 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.
OK, I will check if this runs on Strawberry Perl. While it was a very
handy distribution PxPerl is no longer maintained, so if the failure is
specific to that compilation there is no urgent need to fix it.
But perhaps ... could there be be something like a "portability" section
in the docs? Just as an idea, as without such notes a reader without
special Windows API insight could expect things to work exactly as
described, so such a section could be helpful.
For the general signal handling on Windows, I did not use the Windows
API for a few years now and of course I trust you for all the details,
but I am a bit irritated to hear it should not work in general as from a
users point of view I know that %SIG worked under DOS and Windows, at
least for SIGINT, so I suppose a standard Perl user would just "expect"
things to work to this degree, or again I suggest to add a compatibility
note. But the failure might be very specific to PxPerl ...
>
>> * 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, [detailed explanation]
Thanks for this description, I wasn't aware if this.
>> * 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).
Yes, it was a very simple callback indeed.
For the error checking, sorry to mention the docs once more but could it
... ? ;-)
> 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.
Ok, thanks again for pointing this out. To sum it up, I really think
these system dependencies are worth to be mentioned in the manual, in
order to make it clear to future users what they can expect on a certain
system.
Greetings
Jochen
