AnyEvent driver for Prima

Marc Lehmann schmorp at schmorp.de
Tue Dec 13 17:26:55 CET 2016


On Tue, Dec 13, 2016 at 02:47:21PM +0100, ambrus <ambrus at math.bme.hu> wrote:
> Hello Dmitry Karasik, Corion, and Schmorp.

Hi everybody.

Dmitry: to make a quick summary for you: there is currently nothing known
that would need to be changed in Prima to make all this work. What this is
about is a) questions about how Prima works and b) possibly improving Prima
so it has more functionality.

All: here are the things that an impl module could provide:

  io + timer               absolutely required (and provided by Prima)
  _poll                    absolutely required (and provided by Prima, AFAIK)
  idle                     can be emulated badly by AnyEvent, but better if event loop provides it
  signal + child           can be almost perfectly emulated by AnyEvent if not interferred with

  time, now, now_update    can be emulated if the event loop doesn't provide it (nice to have)

So, the only thing that would be nice if Prima provided it would be a form
of idle watchers, because AnyEvent cannot emulate this correctly.

The time functionality isn't usually a priority, but might have to be
taken into account (AnyEvent timers are relative to AE::now, so if the
event loop doesn't use the current time at watcher creation time as base,
more work would be needed - most simple if the event loop simply provided
that time. I have no clue what Prima does, but could find out if nobody
else knows :).

Corion, ambrus: there are other things that could be overriden by an impl
module in special cases, but usually io+timer+_poll is enough, and idle is
nice to have.

The difficulties (and the added value of AnyEvent) is that we need to find
out about all the little details, such as whether Prima supports multiple
io watchers per fh, whether it supports fd, whether outstanding event
callbacks will be nullified, what time timers are relative to and probably
a bunch of other things I forgot. (One thing I remembered when skimming some
code was that POE has trouble with overloading, so callbacks needed to be
wrapped in my $new_cb = sub { &$cb }).

Getting these details right is what makes it possible to write event
programs freely without worrying about event loop differences, and without
being surprised.

> == Questions to schmorp ==
> 
> Prima::Utils->post is a function that corresponds to AnyEvent::postpone.  It
> arranges that the event loop calls a callback later, without having to
> bother to set up a watcher object.  Can a driver override this function by
> just defining postpone in the driver package?  Should the driver override
> it?

There shouldn't be a need to overwrite it, because they have different
purposes - initialisation of Prima and AnyEvent are somewhat independent
of each other, so it makes total sense for Prima to call its postpone
functions separately.

> In the API of AnyEvent, when a watcher is destroyed, is the DESTROY method
> allowed to call the callback right then?  EV certainly doesn't do that, but
> I'm asking about AnyEvent in general.

When a watcher is destroyed, AnyEvent must not invoke callbacks anymore, i.e.
if an event library does that, the Impl module must work around that, as
AnyEvent code will not be happy about that at all.

I don't think any of the existing backend libraries do that - that's one
thing almost all event libs get right, astonishingly enough.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the anyevent mailing list