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