=head1 EV - (noch) ein Event-Modell für Perl

=head1 Was?

EV ist ein Perl-Modul, das Ereignisgesteuertes Programmieren
unterstützt. Darin unterscheidet es sich erst einmal nicht von anderen
dedizierten Modulen wie "Event" oder die in jedes Toolkit (Gtk, Tk etc.)
eingebaute Ereignisverarbeitung.

EV ist des weiteren eine Schnittstelle zur "Libev"-Bibliothek, eine Art
Libevent-Klon, und erbt deshalb deren Features (worin sich EV nun von
einigen anderen Modulen unterscheidet):

=over 4

=item Korrektheit

Die meisten Ereignis-Bibliotheken funktionieren gut, solange nichts
unvorhergesehenes passiert.

Die meisten versagen kläglich, wenn die Systemuhr verstellt wird
(Zeitsprünge): Aus einem 10s-Timeout können bei Tk (Event, Glib etc.)
problemlos mal Jahre werden, aus einem Tag wenige Sekunden. EV unterstützt
sowohl relative Timer ("wecke mich in 10 Minuten auf, egal ob ntpd die
Uhr ändert oder nicht) als auch absolute Timer ("wecke mich 2008-10-10
12:17:23.445 auf, egal wie lange das wirklich dauert" oder gar "wecke
mich zur nächsten Mitternacht auf"), was kein anderes mir bekanntes
Event-Modell unterstützt.

Registriert man bei Tk (Event::Lib, ...) zwei Watcher auf denselben
Filehandle, so kann einer davon verloren gehen (nicht notwendigerweise
immer der ältere oder neuere).

Stellt man bei Event die "richtigen" Prioritäten ein, kriegt man eine
stetig wachsende Event-Queue die nicht kleiner wird (was allerdings selten
in Out-Of-Memory-Situationen endet, denn Event wird vorher zu langsam).

Das alles sind Kleinigkeiten - bis das Programm deshalb mal "hängt", 100%
Rechenzeit verbraucht oder gar sporadisch versagt.

Außerdem haben viele Event-Modelle (Event, Glib, Tk...) ein von Perl
abweichendes Objektmodell: verliert man beim Event oder Glib die Referenz
auf den Watcher, so hat man bestenfalls ein Memory-Leak. Die EV-Watcher
bestehen genau so lange, wie Referenzen darauf zeigen wie jedes andere
Perl-Objekt auch.

Fork ist ein ganz spezielles Problem: wenige Event-Bibliotheken
unterstützen es direkt, vor allem diejenigen, die Epoll, Kqueue
o.ä. benutzen, da diese Schnittstellen sehr fork-feindlich sind. EV
unterstützt fork indem es den Kernel-Zustand im Kindprozess automatisch
wiederherstellt, sofern es benutzt wird.

=item Geschwindigkeit

EV benutzt "die richtigen" Algorithmen zur Verwaltung: Heaps für die
Verwaltung der Timer (keine lineare Liste oder ähnliches wie alle
anderen), Arrays, wenn es um viele Watcher geht, Listen, wenn es nur
wenige (meist einen) geht. Auch geht Libev nicht vor jedem Pollen alle
seine Watcher (Event, Glib, ...) durch um zu sehen ob sie noch alle da
sind.

Dadurch skaliert EV nicht nur hervorragend in die Bereiche von
hunderttausenden Filehandles und Timern (falls man das braucht), sondern
ist auch mit wenigen davon sehr schnell (was mindstens genauso wichtig
ist).

Auch die Perl-Schnittstelle selbst wurde geschrieben, um unnötige
Laufzeitkosten zu vermeiden: EV erzeugt einen Watcher immerhin 40 mal
schneller als Event und fast viermal so schnell wie Glib, womit EV +
AnyEvent immer noch schneller sind als "nacktes" Glib.

Auch der Speicherverbrauch ist sehr gering: EV-Watcher sind schlichte
geblesste Strings die den Libev-Watcher enthalten. Diese wiederum sind im
Vergleich mit anderen Bibliotheken recht klein (weniger als 100 Bytes).

=item Skalierbarkeit

Nicht nur die Algorithmen, auch die Schnittstelle zum Betriebssystem muss
skalierbar sein, und das bedeutet leider auch: nicht portabel. Jedes
Betriebssystem braucht sein eigenes Rezept und daher auch sein eigenes
Backend: Libev unterstützt Epoll, Kqueue und Solaris' Event Ports.

Einige Backends sind sehr begrenzt (Kqueue z.B. ist auf fast allen System
kaputt und supported bestenfalls Sockets) aber in andere Backends
integrierbar, so kann man z.B. ein Kqueue-Backend (supported nur Sockets
zuverlässig auf FreeBSD) in ein "herkömmliches" Poll-basiertes Backend
integrieren.

=item Watcher-Typen

Neben den üblichen I/O Watchern und Timern (derer es zwei grundsätzlich
verschiedene Typen in EV gibt), bietet EV noch speziellere
Watchertypen für POSIX-Signale, Prozess-Watcher, Idle-Watcher (für
"Hintergrundprozesse"), Prepare/Check-Watcher, mit denen man EV-fremde
Event-Modelle oder -Benutzer integrieren kann und Stat-Watcher, mit denen
man Dateisystemobjekte auf Veränderungen überwachen kann. Ganz spezielle
Watcher, um C<fork()> zu erkennen oder andere Backends zu integrieren gibt
es natürlich auch.

=item Kompatibilität

EV wird von AnyEvent voll unterstützt, so daß Module oder Programme, die
AnyEvent benutzen, ohne Quellcodeänderungen sofort mit EV benutzt werden
können.

=item C-Schnittstelle

Das EV-Modul exportiert die komplette Libev-API auch auf XS-Ebene, was
so nur noch Event bietet (bei anderen Modulen muss man auf positive
Eigenschaften von Shared-Libraries vertrauen).

=back


=head1 Warum?

EV ist, wie die zugrunde liegende Libev, sehr jung (Ende 2007 erschien
die erste Version), und die Entstehung war mehr Zufall als Absicht: Seit
ca. 1998 benutze ich regelmäßig und viel das Event-Modul, welches
problemlos als das ausgereifteste der verfügbaren Event-Module gelten
durfte.

Im Laufe der Jahre stieß ich auf eine Menge kleinerer Probleme mit anderen
Event-Modellen (siehe weiter oben), doch die Anstrengung, eine eigene
Bibliothek zu schreiben, wollte ich nicht aufbringen.

Speicherverbrauch war eigentlich nie ein Problem, die Beschränkung auf
C<select> und C<poll> schon eher, aber man hat ja schnelle Rechner die
das kompensieren (und wenn man nicht drauf achtet, was die Rechenzeit
verbraucht, stört es ja sowieso nie).

An die echten Fehler in z.B. Event gewöhnt man sich mit der Zeit, bzw.
findet mehr oder weniger akzeptable Umleitungen um das Problem, oder
vermeidet den Einsatz in solchen Fällen ganz.

Eines Tages kam jedoch die Notwendigkeit, wirklich viele Filehandles
effizient zu verwalten, und da Libevent sowas wie der Standard für
Performance zu sein schien und es dafür keine Perl-Schnittstelle gab
(das ist falsch, es gab eine, nämlich C<Event::Lib>, aber ich habe sie
trotz suchens auf CPAN nicht wahrgenommen), fing' ich an, eine eigene
Schnittstelle zu Libevent zu schreiben.

Wenig erfreut war ich, als ich herausfand, daß Libevent die gleichen
Probleme wie Tk hat (nicht mehrere Watcher auf einem Filehandle) und auch
nicht wenige Schwächen in der API. Das Erlebnis war derart frustrierend,
daß ich mich entschieden habe, endgültig 'mein eigenes Ding' zu machen. Wie
erwartet, war es mehr Arbeit, als ich eigentlich investieren wollte,
aber nach einigen Monaten hatte ich etwas gebrauchsfähiges, daß sogar
bei Benchmarks gegenüber dem "Standard" (nämlich Libevent) hervorragend
abschneidet.

Da die meisten meiner Module AnyEvent benutzen, und die API von EV (im
Geiste...) der von Event ähnelt, war die Umstellung aller meiner wichtigen
Projekte (gvpe, rxvt-unicode, Deliantra, mein Webserver sowie mehrere
kommerzielle Anwendungen) kein Problem, was natürlich ein sehr guter Test
für das Modul war (und ist).

EV ist somit das Ergebnis von knapp 10 Jahren Erfahrung mit
anderen Event-Modellen, deren Stärken und Schwächen und deren
Perl-Schnittstelle: alle mir bekannten Probleme wurden adresssiert.


=head1 Wie?

Nach so viel Blabla wird's Zeit für Code-Beispiele.

Einen langweiligen Timer realisiert man so.

   use EV;

   my $timer = EV::timer 1, 2, sub {
      warn "zeitstempel: " . EV::now;
      warn "man rief' mich auf nach 1s dann alle 2s. yeah.";
   };

   EV::loop;

Das gibt nach einer Sekunde ein warn, und danach alle zwei Sekunden, bis
in alle Ewigkeit/Reset/SIGINT etc.

EV::loop kehrt automatisch zurück, wenn es keine aktiven Watcher mehr gibt
(das nennt man "Deadlock"):

  my $delay = EV::timer 1, 0, sub {
     warn "nur einmal nach 1s werde ich aufgerufen.\n";
  };

  EV::loop;

Das läuft nur für eine Sekunde. Wichtig ist, daß man das Watcher-Objekt,
das der Konstruktor liefert, auch aufbewahrt, denn wenn man es vergisst,
wird der Watcher automatisch deaktiviert. Hier kehrt C<EV::loop> sofort
zurück, wenn keine sonstigen Watcher aktiv sind, denn der Timer wird
erzeugt, gestartet und sofort wieder gelöscht:

  EV::timer 10, 10, sub { };
  EV::loop;

I/O-Watcher gehen genauso einfach. Das folgende Beispiel "loop"ed so
lange, bis man auf STDIN eine Zeile die mit C<q> beginnt, eingibt (z.b.
"quit"):

  my $stdin_watcher = EV::io *STDIN, EV::READ, sub {
     my $line = <STDIN>;

     # $_[0] enthält das watcher-objekt
     $_[0]->stop if $line =~ /^q/;
  };

  EV::loop;

Alternativ kann man den Watcher auch "einfach" C<undef>'en (die
Sichtbarkeit von my-Variablen in Perl macht das ein bißchen eklig):

  my $stdin_watcher;
  $stdin_watcher = EV::io *STDIN, EV::READ, sub {
     my $line = <STDIN>;

     undef $stdin_watcher if $line =~ /^q/;
  };

  EV::loop;

=head2 Spezialitäten

Nach dem Standardkram, hier ein paar Spezialitäten, die so wahrscheinlich
nur mit EV gehen.

=over 4

=item Ein Watcher, der jeden Tag um Mitternacht lokaler Zeit seinen
Callback aufruft (genauer: zur nächsten Mitternacht nach 23:59:59 des
aktuellen Tages. Für Details muß ich auf die Manpage verweisen):

   use EV;
   use Time::Local;

   my $geisterstunde = EV::periodic 0, 0, sub {
      my ($w, $now) = @_;

      # berechne den nächsten Zeitpunkt des "Feuerns":
      my ($y, $m, $d) = (localtime $now)[5, 4, 3];
      1 + timelocal 59, 59, 23, $d, $m, $y
   }, sub {
      warn "buh!";
   };

Der erste Callback berechnet auf Zuruf von EV die nächste Mitternacht.
Sollte sich die Systemzeit verändern (z.B. ein paar Jahre zurückfallen),
ruft EV den Callback automatisch erneut auf.

=item Überwache F</var/log/messages> auf Veränderungen (die Größe
sollte sich dabei verändern: Wenn auch mtime-Änderungen überwacht werden solle, wird es
etwas komplexer, wie in der Manpage beschrieben):

   my $logwatcher = EV::stat "/var/log/messages", 10, sub {
      warn "/var/log/messages size is now ", ($_[0]->attr)[7];
   };

=item Überwachung einer Perl-Variable auf Veränderung zwischen zwei
Iterationen der EV-Ereignis-Schleife:

   my $var;

   my $oldval = $var;
   my $checkvar = EV::prepare sub {
      if ($oldval ne $var) {
         warn "variable has changed from $oldval to $var\n";
         $oldval = $var;
      }
   };

Ein C<prepare>-Watcher wird ausgeführt bevor EV nach neuen Ereignissen
Ausschau hält, während ein C<check>-Watcher direkt danach ausgeführt
wird. Auf diese Weise kann man EV-fremde Ereignisse in EV integrieren,
z.B. kann man in einem C<prepare>-Watcher neue Watcher erzeugen für z.B.
die Sockets von C<Net::SNMP> während man in einem C<check>-Watcher dann
auf entsprechende Ereignisse reagieren kann.

=item Einbetten von Kqueue in ein anderes Backend (z.B. für FreeBSD, Mac
OS X), damit man wenigstens Sockets effizient benutzen kann:

   my $socket_loop;

   # Erzeuge eine Kqueue-loop WENN Kqueue unterstützt wird UND NICHT
   # schon für die Standard-Schleife verwendet wird:
   if (
     (EV::backend & (EV::BACKEND_POLL | EV::BACKEND_SELECT))
     && (EV::supported_backends & EV::embeddable_backends & EV::BACKEND_KQUEUE)
   ) {
     $socket_loop = new EV::Loop EV::BACKEND_KQUEUE | EV::FLAG_NOENV;
   }

   # Ansonsten benutze die Standard-Schleife:
   $socket_loop ||= EV::default_loop;

   # Erzeuge einen Socket-Watcher:
   my $watcher = $socket->io ($socket_fh, EV::READ, sub { ... });

Statt die globalen Konstruktoren in EV zu verwenden kann man sie auch
über Methodenaufrufe eines EV::Loop-Objektes erreichen.

=item Benutzung von EV von XS aus.

Im Makefile.PL:

   use EV::MakeMaker;

   WriteMakefile (EV::MakeMaker::ev_args (
      ... normale MakeMaker-Argumente
   ));

Im .XS-File:

   #include "EVAPI.h"

   static ev_timer mytimer;

   static void
   mycb (EV_P_ ev_timer *w, int revents)
   {
     // zuerst nach 1s, dann alle 2s
   }

   ...

   BOOT:
      I_EV_API ("<modulname>");
      ev_timer_init (&mytimer, mycb, 1., 2.);
      ev_timer_start (EV_DEFAULT, &mywatcher);

=back


=head1 Und wie noch?

Auf CPAN gibt es einige Module, die sich direkt oder indirekt mit EV beschäftigen.

=head2 Module, die direkt mit EV in Bezug stehen

=over 4

=item EV::ADNS

Eine Schnittstelle zu libadns, einer asynchronen DNS-Resolver-Bibliothek,
die sich in EV integriert. Ein gutes Beispiel, wie man eine "EV-fremde"
C-Bibliothek in libev/EV integriert (auf XS-Ebene).

=item Net::SNMP::EV

Ein Hack, der die Non-Blocking-Aufrufe des Net::SNMP-Moduls in EV
integriert: Net::SNMP unterstützt parallel Anfragen, benutzt aber sein
eigenes, internes, Event-Modell. Dieses Modul bildet es auf EV ab.

Einfaches Laden genügt und schon benutzt Net::SNMP für I/O und Timer das
EV-Modul.

Das Modul ist ein gutes Beispiel dafür, wie man "EV-fremde" Perl-Module
in EV integrieren kann (auf Perl-Ebene).

=item Glib::EV

Dieses Modul ersetzt das "backend" (normalerweise poll oder select) von
Glib (bzw. libglib) durch EV. Dies ist üblicherweise (z.B. wenn man
epoll verwendet) etwas langsamer als Glib selbst, wenn man jedoch wenige
Glib-Watcher (z.B. nur die von Gtk+) und viele (also mehr als 1-2 :)
EV-Watcher verwendet, ergibt dies einen Nettogewinn, vor allem, weil Glib
die ineffizienteste Implementation eines Event-Modells ist, die ich je
gesehen habe.

Laden des Moduls genügt, man muss jedoch die Hauptschleife von Glib
oder Gtk+ benutzen, C<EV::loop> hilft nicht viel, da Glib die Kontrolle
behalten muss.

Arbeitet ähnlich wie EV::ADNS, ist aber komplexer.

=item EV::Glib

Mit diesem Modul kann man EV-Watcher in bestehenden Glib-Programmen
benutzen.

Fast identisch mit Glib::EV, jedoch wird hier der "MainContext" von Glib
in EV integriert, d.h. die Watcher von Glib werden bei Iterationen von EV
mitgeprüft. Dies ist genauso ineffizient wie C<Glib::EV>, es amortisiert
sich aber sobald man einige EV-Watcher benutzt.

Laden des Moduls genügt, man muss jedoch die Hauptschleife von EV
aufrufen, was dazu führt, daß sowohl die EV-eigenen als auch die
Glib-eigenen Watcher betreut/abgefragt werden.

Mit diesem Modul kann man Glib (doer Gtk) in einem EV-Programm benutzen.

=item POE::Loop::EV

Offenbar ein Backend zu EV von POE. Hab's nicht ausprobiert, die Kerle
sollten aber AnyEvent benutzen, damit kriegen sie automatisch EV und alles
andere was AnyEvent unterstützt.

=back

=head2 Module, die EV benutzen können

=over 4

=item AnyEvent

AnyEvent unterstützt C<EV> (und C<Coro::EV>) explizit, d.h. bestehende
Anwender von AnyEvent kommen sofort in den Genuß von EV.

AnyEvent + EV ist sogar schneller als die meisten (bzw. alle von mir
getesteten) Event-Module, und das, obwohl AnyEvent vergleichsweise viel
Aufwand leisten muss.

=item Coro, Coro::EV

Die Filehandle- und Timer-Abstraktionen von C<Coro> (C<Coro::Handle>,
C<Coro::Socket>, C<Coro::Timer>) unterstützen EV direkt (über
C<Coro::EV>). EV ist das effizienteste direkt unterstützte Event-Modul in
C<Coro>.

C<Coro::EV> hat neben der Unterstützung von C<Coro::Handle> noch
Hilfsfunktionen, um einmalige Verzögerungen u.ä. in Coroutinen zu
benutzen.

Sollte C<EV::ADNS> installiert sein, so wird es von C<Coro::Util> (und
damit auch C<Coro::Socket>) für DNS-Anfragen benutzt, statt einen
separaten Prozess zu forken (was sehr langsam sein kann).

=item IO::AIO / Coro::AIO

Haben direkt nichts mit EV zu tun (außer, daß sie mit EV gut
funktionieren), aber für jedes ereignisgesteuerte Programm ein Muss, da
man damit ereignisgesteuert (und asynchron) auf das Dateisystem zugreifen
kann, mit Coro::AIO sogar ähnlich einfach wie mit den eingebauten
Perl-Funktionen.

=item BDB / Coro::BDB

Was IO::AIO für's Dateisystem ist, ist BDB für die Berkeley DB, nämlich
ein Modul, mit dem man ereignisgesteuert die Berkeley DB benutzen kann.

=back

=head2 Werbung

Ok, pure Werbung, aber es gibt noch andere Programme, die Libev benutzen.

=over 4

=item GVPE, das GNU Virtual Private Ethernet

In der nächsten (2.2) Release wird es Libev benutzen. Bringt total viel :->

   http://savannah.gnu.org/projects/gvpe

=item Rxvt-Unicode

Das allerbeste Terminal überhaupt, vor allem, weil es einen
Perl-Interpreter embeddet. Und dazu benutzt es (ab Version 8.4 oder so)
auch Libev. Leider ohne EV, sondern mit eigener Perl-Schnittstelle, aber
na gut, man kann nicht alles haben.

   http://software.schmorp.de/pkg/rxvt-unicode.html

=item Deliantra

Das allergeilste Online-RPG wo gibt, vor allem, weil es Perl embeddet,
einen ganzen vollen Interpreter. Nicht nur, es benutzt auch Coro, IO::AIO,
BDB uvm., und der OpenGL-supergeile-Grafik-mach-Client ist ebenfalls
in Perl geschrieben und benutzt EV, BDB... den Rest kann man sich
vorstellen. Ein Must-See-Must-Have, vor allem wegen des super Retro-Stils!

   http://www.deliantra.net/

=item OpenMPI

Wird, nach eigener Aussage, in der nächsten Release ebenfalls Libev
benutzen. Kein embeddetes Perl in Sicht.

   http://www.openmpi.org/

=back


=head1 Hä?

Ich kann (bzw. wollte) hier nur eine kurze Übersicht geben bzw. einen
Geschmack vermitteln und eventuell neugierig machen.

Mehr Informationen gibt es auf der libev-Manpage:

   http://libev.schmorp.de/

Von dort gibt es auch einen Link zu EV (der Perl-Schnittstelle), dessen
Doku, und einem Benchmark mit Libevent:

   http://pod.tst.eu/http://cvs.schmorp.de/EV/EV.pm
   http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod
   http://libev.schmorp.de/bench.html

=head1 Autor

Marc Lehmann <schmorp@schmorp.de>.