* Marc Lehmann <schmorp@schmorp.de> [2012-02-02 20:55]: > On Thu, Feb 02, 2012 at 04:28:16PM +0000, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote: > > * The implementation of the loop_once method requires the use of an > > undocumented AnyEvent method (one_event before version 6, _poll > > thereafter). This happens to work at the time of writing, but as > > it is undocumented it may be subject to change. > > It does not work "at the time of the writing" vecause one_event wasn't > even implemented by all backends. > > I think you fundamentally misunderstand AnyEvent - you think AnyEvent > is just another event module, it is not. The closest thing AnyEvent > has that is that is AnyEvent::Loop. > > AnyEvent is just an adaptor to existing event loops. It does not > block, like IO::Async does. Marc, an option to resolve is to add an interface similar to what Plack has for its handlers, where each handler has a way to communicate its capabilities, e.g. whether it supports streaming. Then middlewares or apps which require streaming can throw an error when run under servers that do not support it. That allows Plack to support more than just the absolute least common denominator of server semantics in its handlers: it’s up to the user to pick a server that supports enough. By analogy IOALoopAE could mention in POD that it requires `one_event` support and AE could let it know whether it is running under an event loop that provides that, which IOALoopAE could then check and bail out (possibly lazily iff client code actually tries to use the `later` feature). That way AE could support *common* event loop semantics instead of just the *universal* semantics. Effectively AE already does that – I do not recall what it was but there was a use case that the docs describe as working under Coro or the like, but not under non-concurrent event loops. There just is no formalised system for event loop feature support declaration. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next