Front page | perl.perl5.porters |
Postings from February 2012
Many others have weighed in on this in political directions; I'm going
to keep this mail purely technical at the core of the issue. I'll write
a second one to address the wider concerns afterwards.
On Thu, Feb 02, 2012 at 02:21:22AM +0100, Marc Lehmann wrote:
> So here are the facts:
>
...
> - The required backend mechanics ("internals") for IO::Async::Loop::AnyEvent or
> what it's called have been REMOVED around the same time as the error has
> been added.
> - IO::Async can use e.g. AnyEvent::Loop to be compatible, which _has_
> the required functionality.
IO::Async::Loop::AnyEvent stays entirely within the documented AnyEvent
API except in one case. That one case is to support IO::Async::Loop's
"later" method; a method that schedules a CODE reference to be invoked
"soon", ie. after the current round of IO events, but before anything
else. I recall mention elsewhere in this thread of other wrappers having
to perform similar.
I do not believe AnyEvent has such a method, but I may be mistaken. If
instead you can point out to me how to achieve this, then I can fix
IO::Async::Loop::AnyEvent to use that instead, and it will no longer
have to abuse internals. Doing so will return it to simply using
published APIs and therefore ought to be able to cooperate fully with
everything else.
> If there are newer versions of IO::Async::Loop::AnyEvent that happen to
> work (which would require some changes to IO::Async, which is an event
> library, so can't sit on top of anyevent and work at the same time), then
> it's easy to remove this check, or indeed override the check itself, after
> all, IO::Async::Loop::AnyEvent didn't shy back from hacking internals
> before, so nothing really changed.
Again, I believe all that's required on AnyEvent's side is to provide
such a behaviour. Perhaps it could be documented as the following:
-----
TICKER WATCHERS
$w = AnyEvent->tick (cb => <callback>);
This will invoke the callback once at some point in the near future,
before any further IO events are processed, provided the watcher object
has not yet been destroyed.
Ticker watchers are useful when there is a need to do something in the
near future, but not while the current round of IO events are being
processed. The callback will be invoked when the events that are
currently known about have been processed, but before a new round of
them has been determined.
These may be considered as "high-priority" idle watchers, because they
will be scheduled even if other events are pending, unlike idle watchers
which only run when the event loop is otherwise doing nothing.
-----
I would be happy to write unit tests, documentation, etc... if you'd
accept a patch.
Once that is in I would be happy to rewrite IO::Async::Loop::AnyEvent to
only use this published API and no longer abuse internals.
Thanks,
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
Thread Previous
|
Thread Next