Mojo implementation?

[Felipe Gasper]

> On Oct 24, 2020, at 4:46 PM, Marc Lehmann <schmorp at schmorp.de> wrote:
> 
> On Fri, Oct 23, 2020 at 02:06:19PM -0400, Felipe Gasper <felipe at felipegasper.com> wrote:
>> 
>> 	I notice that there’s no AnyEvent::Impl::Mojo module … is this by design, or has just no one wanted to build such an interface?
> 
> I didn't know Mojo was an event loop (it looks to be some kind of web
> framework to me). In that case, the correct way to proceed would be for
> Mojo to *use* AnyEvent: Using AnyEvent as a generic event loop in higher
> level code is what it is designed for.
> 
> Doing it the wrong way around means Mojo could never use AnyEvent itself.
> 
> Digging a bit deeper, it seems Mojo already uses EV, which would make it
> trivially compatible with AnyEvent, and according to the author the way it
> is meant to be used with AnyEvent.

Mojo::IOLoop is the same idea as AnyEvent, just reinvented for Mojolicious. Like AnyEvent, Mojo::IOLoop *can* use EV but comes with its own pure-Perl event loop. If EV isn’t available, then both Mojo and AE will use their own loops, which of course doesn’t work.

We don’t use EV, and when we’ve tried it some of our tests have broken. That may indicate bugs on our end that should fix, but AnyEvent::Loop has at least been working for us, so that’s what we have. For Mojo and AE to coexist in our application, then, something analogous to AnyEvent::Impl::IOAsync is needed: a bridge that allows AnyEvent to call into the other event loop abstraction--in this case, Mojo rather than IO::Async--without caring about which actual event loop runs underneath.

Alternatively, Marc’s idea of having Mojo call into AnyEvent--a “Mojo::Reactor::AnyEvent” module--might work, but my understanding is that it’s problematic for IO::Async to call into AnyEvent, so I would think Mojo would have the same problem?

Marc, if you’re amenable to the AnyEvent::Impl::Mojo idea I can whip up a proof-of-concept?

Thank you!

-FG