Where's AnyEvent's run_one_timeslice?

Marc Lehmann schmorp at schmorp.de
Sat Aug 8 05:51:42 CEST 2015


On Fri, Aug 07, 2015 at 08:02:40AM -0700, Mike Schilli <office at perlmeister.com> wrote:
> involve changing a morass of code, which is the reason I've held off on it
> until now, but it seems there's no easy way out.

Indeed, and I understand the pain involved, being a "victim" of this myself.

Have you explored:

a) actually blocking, as in, reverting to full-process-blocking for the
duration of the model box - I would *guess* it can't be done, but who knows.

b) making the user responsible to set some "modality hook", i.e. a callback
that invokes one_event for you? e.g.

   # main program
   use EV; # we use EV
   use Curses::UI;

   Curses::UI->set_one_event (sub { EV::run EV::RUN_ONCE });

   # do more Curses::UI stuff

   EV::loop; # run the thing

It's not conceptually very different to Qt users to have to initialise Qt
before watchers, or IO::ASync users having to provide the correct loop to
AnyEvent.

The default implementation could die, or even try some common backends,
such as AnyEvent::Loop::Perl, EV, Event, based on $AnyEvent::MODEL, before
giving up.

c) only do the equivalent of the default implementation from b), and add
event loops based on user demand.

There might be other solutions (deprecate and dump those functions for
example), but I can't really say what their imnpact would be :)

-- 
                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