Asynchronous programming with AnyEvent

View more presentations from Tatsuhiko Miyagawa.

via www.slideshare.net

Here's my slides about AnyEvent YAPC::Asia 2009 day 1. I realized this is the first talk in years that I give a talk about software/modules that are not mine, though it indeed has a couple of examples from my AnyEvent::* modules.

Rocco, the author of POE pointed out that slides 19-21 are misleading since POE also has the POE::Loop concept so that you can run your event loop under different backends like EV or Gtk. While that is true (and that is great), POE still can't run with the other main loop, like IO::Async::Loop->loop_forever. You still need to call POE::Kernel->run and to do so you should rewrite your main program to use POE everywhere, since existent IO::Async based program can't run any of POE::Component, which is totally possible with AnyEvent and AnyEvent::* modules.

UPDATE: see the comment below for Rocco, maybe I was misunderstanding and POE::Session->create works with other event loops like AnyEvent modules. I still love AnyEvent's callback style cleaner and much saner Perl-ish API but yeah, if that is true i draw it back from the POE-AnyEvent battle table.

Comments

[twitter.com/rcaputo]

I respectfully disagree, and I have code to back me up.

POE runs with other main loops. In fact, POE::Kernel->run() is often implemented in terms of native event dispatchers. POE::Loop classes implement event watchers using native watchers, and native callbacks are used to generate POE events.

Depending on the POE::Loop implementation, POE::Kernel->run() need not be called upon to dispatch events. This is CPAN, so your mileage may vary. If you're interested in improving CPAN, submit bug reports to the appropriate queues.

I mentioned I had code. Here's a working example of POE code and native Glib code running together in the same program, using Glib's MainLoop:

use Glib;
use POE;

POE::Session->create(

  inline_states => {

    _start => sub { $_[KERNEL]->delay(tick => 1) },

    tick => sub {

      print "poe tick at ", time(), "...\n";

      $_[KERNEL]->delay(tick => 1);

    },

  },

);

my $glib_timer = Glib::Timeout->add(

  500, sub {

    print "glib tick at ", time(), "...\n";

    return 1;

  }

);

# Dispatches Glib and POE events.

Glib::MainLoop->new->run();

Of course you can call POE::Kernel->run() instead of Glib's main loop. This is a good thing. A single, portable run() method covers every supported event loop.

[twitter.com/rcaputo]

By the way, your style for pre-formatted text in comments seems a bit vertically sparse and not very monospaced. The preview style looked a lot better, although the textarea was kind of small.

[miyagawa]

Rocco, thanks for the comment. Hmm, that was definitely something different from what I had in my mind and experimented with. I apologize for the confusion and will update the blog post to mention your comment.

[remlin]

Too bad you have to rely on undocumented features (POE::Kernel says you have to call the run method). Looks like a hack to prove a point.

Even if it is possible with POE, you cannot fault people like miyagawa to misrepresent things when the official documentation supports his slides.

[twitter.com/rcaputo]

While it "looks like a hack", a small example is much more reasonable for a blog comment than a larger, more complete program. I'm glad that it concisely proved my point.

As for POE's documentation, it does explain how to call run() so that it returns right away without taking control of the event loop. I admit it could be clearer. The original included:

POE::Kernel will print a strong message if a program creates sessions but fails to call run(). If the lack of a run() call is deliberate, you can avoid the message by calling it before creating a session. run() at that point will return immediately, and POE::Kernel will be satisfied.

(example)

...

Based on your feedback, I am changing it to read:

POE::Kernel will print a strong message if a program creates sessions but fails to call run(). Prior to this warning, we received tons of bug reports along the lines of "my POE program isn't doing anything". It turned out that people forgot to start an event dispatcher, so events were never dispatched.

If the lack of a run() call is deliberate, perhaps because some other event loop already has control, you can avoid the message by calling it before creating a session. run() at that point will initialize POE and return immediately. POE::Kernel will be satisfied that run() was called, although POE will not have actually taken control of the event loop.

(example)

Note, however, that this varies from one event loop to another. If a particular POE::Loop implementation doesn't support it, that's probably a bug. Please file a bug report with the owner of the relevant POE::Loop module.

...

If this change is unsatisfactory or you encounter any other problems, please send bug reports and/or patches to POE's bug queue at rt.cpan.org.

Constructive dialoge with CPAN authors will increase the rate of CPAN improvement. You will want to do this if you're interested in helping Perl be a friendlier, more welcoming platform for open source development.