MuEvent: AnyEvent lookalike for Perl 6

Trying to struggle with Select in Parrot, I accidentally discovered that its Socket has a .poll method. What a trivial, yet satisfying way to have some simple non-blocking IO. Thus, MuEvent was born.

Why MuEvent? Well, in Perl 6, Mu can do much less than Any. MuEvent, as expected, can do much less than AnyEvent, but it’s trying to keep the interface similar.

You’re welcome to read the code, and criticise it all the way. Keep in mind that I can no idea how should I properly write an event loop, so bonus points if you tell me what could have been done better. I don’t expect MuEvent to be an ultimate solution for event-driven programming in Perl 6, but I hope it will encourage people to play around. Have an appropriate amount of fun!


6 Comments on “MuEvent: AnyEvent lookalike for Perl 6”

  1. Ian F says:

    Looks great. tadzik++

    Looking through the code, I wondered if the following lines in the run-once sub
    $seen-action = run-timers();
    $seen-action = run-sockets();
    would work better like
    $seen-action ||= run-timers();
    $seen-action ||= run-sockets();
    (hope I got the syntax right)


    • ttjjss says:

      This way, we get

      $seen-action = $seen-action || run-sockets()

      So socket handlers aren’t ran if we got the timed event in the current iteration. That was not my intention, $seen-action is only used to run idle events only if no other events have been ran.

      • Ian F says:

        Ah, very true.
        Could you use something like
        $seen-action = run-sockets() || $seen-action;
        to ensure the socket handlers are run but also ensure that the idle events are not run if there was a timed event but not a socket event?

      • ttjjss says:

        Why would you do that rather than the current solution? So that idle events are run regardless of the result of run-sockets()? Then you could just ignore the return value. I think I don’t see the use case you’re talking about, could you provide an example?

  2. Ian F says:

    Sure, I’ll try…

    With the current solution, any value returned by run-timers() will be overwritten by the return value of run-sockets(). If run-timers() returns True and run-sockets() returns False, then $seen-action will be False and the idlers callbacks will be called.

    I am assuming that you only want the idlers to be called if there is neither a timer event nor a socket event.

    If this is the case, then I think that something like

    my $seen-action = False;
    $seen-action = run-timers() || $seen-action;
    $seen-action = run-sockets() || $seen-action;

    would allow the return values of both run-timers() and run-sockets() to be taken into account.
    e.g. if run-timers() returns True and run-sockets() returns False, then $seen-action will be True and the idlers callbacks won’t be called.

    If my assumption is false, then I apologise for wasting your time. :-)

    • ttjjss says:

      Oh, of course you’re right! Didn’t see that one coming. I’ll patch it right away, thanks for your patience in explaining it :)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s