Un peu de pratique...

Voyons maintenant comment tout cela s'articule. Lorsqu'une session est créée, elle récupère une liste d'événements auxquels elle doit répondre, avec le callback associé. Chaque callback est une référence de fonction :

        POE::Session->create(
            inline_states => {
                _start     => \&on_start,
                file_ready => \&on_file_ready,
            }
        );

Quand un événement file_ready survient, la fonction correspondante est appelée pour le gérer.

Certains événements sont prédéfinis par POE, tels que _start et _stop appelés lorsque la session est respectivement créée et stoppée. Les autres événements font partie de l'API de la session, et sont choisis librement par le développeur.

Hello, world!

Commençons par le traditionnel programme d'entraînement. Le voici dans toute sa splendeur, version POE :

        #!/usr/bin/env perl

        use warnings;
        use strict;
        use POE;

        POE::Session->create(
            inline_states => {
                _start => sub { print "Hello, world!\n"; }
            },
        );
        POE::Kernel->run();
        exit;

La partie intéressante est bien sûr la création de session. Dans cet exemple, on ne réagit qu'à l'événement _start, et le traitement associé est tellement simple qu'on utilise une fonction anonyme.

Passage de paramètres

Il est possible de passer des arguments à l'événement _start en fournissant un paramètre args à la fonction create(). Le callback les retrouvera dans ses arguments. Reprenons notre "Hello, world!" qui va cette fois saluer en fonction des arguments passés en ligne de commande :

        #!/usr/bin/env perl

        use warnings;
        use strict;
        use POE;

        POE::Session->create(
            inline_states => {
                _start => \&on_start,
            },
            args => \@ARGV,
        );
        POE::Kernel->run();
        exit;

        sub on_start {
            my @args = @_[ARG0 .. $#_];
            print "Hello, @args!\n";
        }

Notez que la fonction on_start() récupère bien ses arguments dans @_... Mais comme un gestionnaire d'événements POE a besoin d'un contexte pour fonctionner, POE va passer d'autres arguments en plus, tels que le kernel, la heap ainsi que beaucoup d'autres choses (objet, session active, etc.).

Pour récupérer les vrais arguments (au sens arguments passés par le développeur), il faut utiliser des constantes définies (et exportées) par POE. Pour les arguments, il s'agit de ARG0 à ARG9. Et s'il y a besoin de plus, comme les vrais arguments sont placés en fin de liste, il est toujours possible d'utiliser ARG9+1 pour le onzième argument, voire $#_ pour l'indice du dernier élément de @_. C'est ce qui est utilisé dans l'exemple ci-dessus.

Passage de messages

Le but de POE est de faire cohabiter plusieurs sessions, chacune gérant son périmètre. POE leur permet de s'échanger des messages.

Prenons donc maintenant le cas d'une application un peu plus évoluée. On va créer deux sessions :

La première, nommée logger, va être chargée d'écrire sur STDERR tout message debug reçu.
La deuxième va juste être chargée de se réveiller périodiquement et d'envoyer un message à logger. Au bout de 10 réveils, elle s'arrêtera.

Cette application n'est pas très utile, d'autant plus qu'on n'a pas forcément besoin de deux sessions pour effectuer cela... Mais elle permettra d'étudier le passage de messages avec POE.

Commençons par regarder la création de logger. Celle-ci doit réagir aux événements debug :

        POE::Session->create(
            inline_states => {
                _start => \&on_logger_start,
                debug  => \&on_logger_debug,
            },
        );

Le callback de départ va mettre en place un alias logger avec la méthode alias_set() du kernel. Celui-ci peut être récupéré via $_[KERNEL], avec KERNEL une autre constante déclarée et exportée par POE :

        sub on_logger_start {
            my $kernel = $_[KERNEL];
            $kernel->alias_set( 'logger' );
        }

Le callback de log proprement dit n'a rien d'exceptionnel, on appelle juste warn() avec tous les arguments reçus :

        sub on_logger_debug {
            my @args = @_[ARG0 .. $#_];
            warn @args;
        }

Passons maintenant à la création de l'autre session :

        POE::Session->create(
            inline_states => {
                _start => \&on_alarm_start,
                tick   => \&on_alarm_tick,
            },
        );

Là encore, rien de nouveau. Mais la fonction d'initialisation est plus intéressante. Comme on ne souhaite se réveiller que dix fois avant de s'arrêter, cela veut dire qu'on doit garder un compteur quelque part. Il est bien sûr hors de question d'utiliser une variable globale. On va donc garder cette information avec les données de la session, c'est-à-dire dans la heap (autrement dit le tas, par analogie avec la partie de mémoire d'un processus où la mémoire sera allouée à coups de malloc()). Chaque session dispose d'une référence à un hash anonyme (par défaut), accessible via $_[HEAP] (HEAP étant là encore une constante définie et exportée par POE). La fonction d'initialisation va aussi armer une alarme, qui devra lancer le message tick au bout d'une seconde :

        sub on_alarm_start {
            $_[HEAP]->{nb} = 0;
            $_[KERNEL]->delay_set( 'tick', 1 );
        }

Le kernel sait quelle session est active à tout moment, il n'a donc pas besoin de cette information pour la méthode delay_set() : celle-ci va poster l'événement tick à la session courante.

Lors de la réception d'un tick, ne reste plus qu'à poster un événement debug à destination de logger grâce à la méthode post() du kernel, incrémenter notre compteur, et si celui-ci le permet, alors relancer une alarme :

        sub on_alarm_tick {
            my ($k,$h) = @_[KERNEL, HEAP];
            $k->post( 'logger', 'debug', 'this is a test: msg ', $h->{nb} );
            return if ++$h->{nb} > 9;
            $k->delay_set( 'tick', 1 );
        }

La méthode post() prend comme arguments la session destinatrice, l'événement à déclencher, et des paramètres éventuels pour le callback du dit événement.

Et voici donc le programme complet :

        #!/usr/bin/env perl

        use strict;
        use warnings;
        use POE;

        POE::Session->create(
            inline_states => {
                _start => \&on_logger_start,
                debug  => \&on_logger_debug,
            },
        );
        POE::Session->create(
            inline_states => {
                _start => \&on_alarm_start,
                tick   => \&on_alarm_tick,
            },
        );
        POE::Kernel->run();
        exit;

        # -- logger
        sub on_logger_start {
            my $kernel = $_[KERNEL];
            $kernel->alias_set( 'logger' );
        }
        sub on_logger_debug {
            my @args = @_[ARG0 .. $#_];
            warn @args;
        }

        # -- alarm
        sub on_alarm_start {
            $_[HEAP]->{nb} = 0;
            $_[KERNEL]->delay_set( 'tick', 1 );
        }
        sub on_alarm_tick {
            my ($k,$h) = @_[KERNEL, HEAP];
            $k->post( 'logger', 'debug', 'this is a test: msg ', $h->{nb} );
            return if ++$h->{nb} > 9;
            $k->delay_set( 'tick', 1 );
        }

On peut remarquer que bien qu'un alias ait été défini pour logger, nul besoin de l'enlever : le kernel détecte que plus aucune session n'est active et arrête donc bien toutes les sessions.

Utilisation avancée

Modulariser le code

Il est généralement plus propre de gérer chaque session dans un module : de cette façon on obtient des composants bien encapsulés, et plus facilement réutilisables.

Dans ce cas-là, le module va fournir une méthode spawn() (c'est une convention de nommage que chacun est libre de respecter... ou non) qui lancera une nouvelle session. Toutes les fonctions de gestion d'événements seront alors dans le module, pour une encapsulation forte.

Une autre méthode de modularisation consiste à utiliser plusieurs objets dans la même session, chacun gérant un ensemble de messages. Il est même possible de mélanger, au sein d'une même session, gestion par objets et gestion par fonctions.

Ainsi, en reprenant l'exemple précédent, et en supposant qu'on a une classe Logger qui dispose des méthodes debug() et error() :

        my $logger = Logger->new( ... );
        POE::Session->create(
            inline_states => {
                _start => \&on_start,
                tick   => \&on_tick,
            },
            object_states => [
                $logger => [ 'debug', 'error' ],
            ],
        );

Ici, le paramètre object_states est identique à inline_states, sauf qu'il attend une référence de liste. En effet, les clefs d'un hash sont automatiquement transformés en chaîne par Perl, et la référence de l'objet serait perdue. Donc on fournit à object_states une liste composée de paires : chaque objet est suivi par une référence vers la liste des messages qu'il va traiter.

Cette liste des messages peut être :

soit une liste de chaînes, auquel cas ces chaînes seront des événements qui seront traités par les méthodes de même nom de l'objet,
soit un hash dont les clefs sont les noms d'événement et les valeurs le nom de la méthode à appeler. Ceci est utile dans le cas où l'API de l'objet ne suit pas l'API de la session, ce qui peut arriver dans le cas où on réutilise des modules du CPAN.

Ainsi, voici l'exemple ci-dessus qui utilise deux objets : le premier pour logger les messages bénins, et un deuxième qui va gérer les erreurs fatales :

        my $logger = Logger->new( ... );
        my $error  = Error->new( ... );
        POE::Session->create(
            inline_states => {
                _start => \&on_start,
                tick   => \&on_tick,
            },
            object_states => [
                $logger => [ 'debug', 'warning' ],
                $error  => {
                    critical  => 'graceful_exit',
                    emergency => 'emergency_exit',
                },
            ],
        );

La session ainsi créée va donc répondre aux événements :

_start et tick avec les fonctions on_start() et on_tick() respectivement,
debug et warning en appelant respectivement $logger->debug() et $logger->warning() (donc des méthodes différentes du même objet),
et enfin critical et emergency en appelant respectivement $error->graceful_exit() et $error->emergency_exit() (donc des méthodes dont le nom diffère du message reçu).

Tout ceci laisse donc énormément de place au développeur pour choisir le type de modularisation souhaité.

POE référence les sessions tout seul

Vous avez très certainement remarqué que les objets POE::Session ne sont quasiment jamais stockés. C'est parce que POE s'occupe de les gérer lui-même, pour plusieurs raisons.

Créer des sessions est relativement banal, et les sauvegarder puis les détruire à la main serait lourd à gérer.
De plus, POE utilise énormément de références circulaires : ce fichier appartient à telle session, telle session gère ce fichier. POE aurait des fuites de mémoire énormes s'il ne gérait pas lui-même tous ces liens et ne les détruisait donc pas plus tard.
Enfin, puisque POE est obligé de gérer ces références de toute manière, cela lui permet de savoir quand une session n'est plus nécessaire, il s'occupera donc de la passer au ramasse-miettes au bon moment.

Envoi de messages à soi-même

Il est fréquent que les sessions s'envoient des messages à elles-mêmes, pour différentes raisons. Il est possible de faire cela en récupérant $_[SESSION] qui est la session courante, et de lui post()-er un message :

        $_[KERNEL]->post( $_[SESSION], $event, @args );

Mais cela est plutôt maladroit pour une opération finalement assez banale. POE propose donc une méthode yield() qui fait exactement cela en beaucoup plus simple :

        $_[KERNEL]->yield( $event, @args );

Puisqu'on parle des messages, ceux-ci sont traités dans un ordre FIFO, c'est-à-dire que les premiers messages lancés seront les premiers livrés.

Remplacement de la heap

POE permet de remplacer la heap par n'importe quel scalaire au moment de la création. Ceci peut être intéressant si on souhaite utiliser un objet afin de vraiment encapsuler l'accès aux données de la session avec des accesseurs comme get_nb() et set_nb() (pour notre exemple ci-dessus). Il faut dans ce cas utiliser le paramètre heap lors de l'appel à create() :

        POE::Session->create(
            # ...
            heap => My::Heap->new( ... ),
            # ...
        );

Chaque session doit gérer un événement `_start()`

L'événement _start notifie à une session qu'elle a démarrée. POE envoie ce message automatiquement car il est très fréquent d'initialiser une session.

Le gestionnaire de l'événement _start() sera déclenché immédiatement. Son but est d'initialiser la session et de créer des choses qui appartiendront à la session. En effet, la session va très certainement s'arrêter immédiatement si elle ne gère rien après le retour du callback de _start(), car POE la passera au ramasse-miettes.

À propos des événements non gérés

Les sessions définissent lors de leur création les événements auxquels elles vont réagir. Lorsqu'une session reçoit par la suite un événement non géré, celui-ci sera discrètement ignoré.

Ce n'est en effet pas une erreur d'envoyer un message à une session qui ne sait pas le gérer. POE va donc le supprimer sans avertissement, ce qui permet à des programmes modulaires de fonctionner quand des sessions optionnelles ne sont pas présentes. Par exemple, on peut imaginer un programme contenant une session de debug qui loggue des informations dans un fichier pendant le développement. Mais quand la session est omise (dans le programme de production), les événements contenant les messages de debug sont tout simplement éliminés, et le programme fonctionne correctement.

Cependant, les messages non traités peuvent être une source d'erreur énervante. Il est en effet banal de mal taper le nom d'un événement, ou d'oublier d'ajouter son handler dans le constructeur de la session. Dans ces cas, les programmes cessent de fonctionner normalement, sans qu'on sache pourquoi. On peut changer POE pour qu'il traite certaines choses optionnelles en tant qu'erreur, ce qui inclut les situations où des événements sont éliminés silencieusement. Il suffit pour cela de définir une nouvelle fonction constante dans le module POE::Kernel, mais avant que celui-ci soit chargé :

        #!/usr/bin/env perl
        use strict;
        use warnings;
        sub POE::Kernel::ASSERT_DEFAULT () { 1 }
        use POE;
        POE::Session->create(
            inline_states => {
                _start => sub { $_[KERNEL]->yield( 'unknown' ); },
            }
        );
        POE::Kernel->run();
        exit;

La fonction ASSERT_DEFAULT déclenche les assertions pour tous les cas marginaux de POE. Il déclenche la validation des paramètres et des valeurs de retour, ainsi que la détection avancée de fuites de mémoire dans POE. Bien sûr, cela va ralentir le programme, mais cela peut toujours être intéressant lors des phases de développement et déboguage.

En lançant l'exemple ci-dessus, le résultat ne se fait pas attendre :

        $ ./unknown.pl
        a 'unknown' event was sent from unknown.pl at 8 to session 2 (POE::Session=ARRAY(0x808b8e8)) but session 2 (POE::Session=ARRAY(0x808b8e8)) has neither a handler for it nor one for _default

Comme le message d'erreur ci-dessus le précise, on peut aussi fournir à la session un gestionnaire pour l'événement _default, qui capturera tous les messages non nommés durant la création de la session. Dans le gestionnaire d'événement associé, $_[ARG0] correspond au nom du message envoyé initialement, et $_[ARG1] est une référence de liste contenant les arguments initiaux du message envoyé. Cela permet de créer un gestionnaire fourre-tout, qui peut être utile pour faire son propre dispatch.

Gestion des signaux

Les signaux POSIX sont aussi gérés via POE. Il suffit pour cela d'enregistrer avec la méthode sig() du kernel les signaux qu'on souhaite traiter en association avec le message qui sera généré lors de cet événement, et le kernel enverra ce signal à toutes les sessions. Le paramètre $_[ARG0] contiendra le nom du signal.

        $_[KERNEL]->sig( USR1 => 'usr1' );

Les signaux dits terminaux (HUP, INT, KILL, QUIT et TERM) arrêtent le programme s'ils ne sont pas gérés. Pour cela, ils doivent utiliser la méthode sig_handled() du kernel pour signifier que le signal a été traité.

Le bon citoyen POE

Du fait de la nature de POE, les programmes ne vont fonctionner correctement que si leurs composants coopèrent entre eux.

Une session qui va appeler sleep() ou toute autre construction qui ne revient pas immédiatement va mettre l'ensemble du programme en pause. Ainsi, les appels à sleep() doivent être remplacés avec des appels à delay_set(), qui appelleront un événement déterminé, avec des arguments éventuels :

        $_[KERNEL]->delay_set( 'tick', 10, @args ); # wait 10 secs

Il est aussi possible de positionner une alarme à une date donnée :

        $_[KERNEL]->alarm_set( 'alarm', $epoch, @args );

De même, une longue boucle peut empêcher les autres sessions de recevoir leur quota de temps. Pour cela, il faut donc les transformer de façon à ce que la boucle soit coupée en petits morceaux :

        sub long_loop_start {
            print "start...\n";
            $_[HEAP]->{i} = 0;
            $_[KERNEL]->yield('long_loop');
        }

        sub long_loop {
            my $h = $_[HEAP];
            if ( $h->{i} < 1_000_000 ) {
                # ... 
                $h->{i}++;
                $_[KERNEL]->yield('long_loop');
            } else {
                print "done.\n";
            }
        }

Bien sûr, appeler un nouvel événement pour chaque itération va énormément ralentir la boucle. Dans ce cas, une solution intermédiaire consiste à faire plusieurs itérations dans le même événement. Par exemple, avec 100 itérations par événement :

        sub long_loop {
            my $h = $_[HEAP];
            my $i = 0;
            while ( $i++ < 100 &&
                    $h->{i} < 1_000_000 ) {
                # ...
                $h->{i}++;
            }
            if ( $h->{i} < 1_000_000 ) {
                $_[KERNEL]->yield('long_loop');
            } else {
                print "done.\n";
            }
        }

Ainsi, la boucle devrait prendre beaucoup moins de temps, tout en permettant aux autres sessions (ou aux autres tâches de la session) d'avoir une chance de s'exécuter.

C'est la même chose pour les appels à die() ou exit() : la tâche faisant cet appel doit bien être consciente qu'elle va arrêter toutes les sessions et les tâches en cours, et non pas elle-même uniquement. Il y a des chances que cela ne soit pas l'effet désiré !

POE distribué

IKC

Rien qu'avec ce qu'on a vu ci-dessus, POE est un framework de choix pour bien des applications. Mais POE ne s'arrête pas là et permet beaucoup plus, en fournissant un moyen de distribuer des applications sur plusieurs machines - ou sur la même machine mais dans des processus différents.

POE permet en fait la communication inter-kernel (ou IKC, Inter Kernel Communication). Ceci est implémenté dans POE::Component::IKC qui fournit tout ce qu'il faut.

Logger implémenté en tant que service

Pour comprendre un peu la puissance d'IKC, reprenons notre session logger vue précédemment. Mais cette fois-ci, on va l'implémenter dans son propre processus, accessible de n'importe quelle session utilisant IKC.

Outre les en-têtes habituels, on va charger la partie serveur d'IKC via POE::Component::IKC::Server :

        #!/usr/bin/env perl
        use strict;
        use warnings;
        use POE;
        use POE::Component::IKC::Server;

Cela va permettre de créer un serveur IKC, qui sera en fait un composant POE utilisant sa propre session. On fournit l'IP (ou le nom), le port sur lequel écouter, ainsi que le nom du serveur qui servira à retrouver ce kernel via IKC. Dans cet exemple, on prend le nom my-server :

        POE::Component::IKC::Server->spawn(
            ip   => 'localhost',
            port => 17000,
            name => 'my-server',
        );

On crée ensuite notre session logger qui va s'occuper de logger les messages. Elle ne diffère pas de celle qu'on a créé dans l'exemple ci-dessus. On peut ensuite lancer le kernel de la manière standard :

        POE::Session->create(
            inline_states => {
                _start => \&on_start,
                debug  => \&on_debug,
            }
        );
        POE::Kernel->run();
        exit;

Pour garder cet exemple aussi simple que possible, la fonction on_debug() ne change pas et fera juste un warn() avec les paramètres reçus. La fonction on_start(), elle non plus, ne change pas tellement. La seule chose différente consiste à publier via IKC notre alias de session ainsi que les messages acceptés dans un contexte de communication inter-kernel :

        sub on_start {
            my $k = $_[KERNEL];
            $k->alias_set('logger');
            $k->call( IKC => publish => 'logger', ['debug'] )
        }

        sub on_debug {
            warn @_[ARG0 .. $#_];
        }

On a donc un serveur en bonne et due forme :

        #!/usr/bin/env perl
        use strict;
        use warnings;
        use POE;
        use POE::Component::IKC::Server;

        POE::Component::IKC::Server->spawn(
            ip   => 'localhost',
            port => 17000,
            name => 'my-server',
        );
        POE::Session->create(
            inline_states => {
                _start => \&on_start,
                debug  => \&on_debug,
            }
        );
        POE::Kernel->run();
        exit;

        sub on_start {
            my $k = $_[KERNEL];
            $k->alias_set('logger');
            $k->call( IKC => publish => 'logger', ['debug'] )
        }

        sub on_debug {
            warn @_[ARG0 .. $#_];
        }

Le client n'est pas tellement plus dur à écrire. Cette fois-ci on va charger la partie client d'IKC :

        #!/usr/bin/env perl
        use strict;
        use warnings;
        use POE;
        use POE::Component::IKC::Client;

On va ensuite créer un client IKC qui va se connecter sur le serveur, en lui fournissant un callback lorsque la connexion sera effective. On ne crée pas d'autre session pour l'instant, car cela ne sert à rien tant que le client n'est pas connecté.

        POE::Component::IKC::Client->spawn( 
            host => 'localhost', 
            port => 17000, 
            name => "client-$$",
            on_connect => \&on_connect,
        );
        POE::Kernel->run();
        exit;

Par contre, lorsque le client s'est connecté, on peut maintenant créer notre session, qui va envoyer un message de debug toutes les secondes. La création de session est tout à fait classique :

        sub on_connect {
            POE::Session->create(
                inline_states => {
                    _start => \&on_start,
                    tick   => \&on_tick,
                }
            );
        }

De même, la fonction on_start() ne change pas beaucoup, mis à part la souscription au service IKC publié par le serveur. Les souscriptions à des services POE distants sont du type poe://<kernel>/<session>/<événement>. Bien sûr, kernel doit correspondre à un nom de kernel tel que publié via le paramètre name, session doit correspondre à un nom de session et de même pour événement. On peut utiliser des jokers à la place, tel que poe://<kernel>/logger/*.

        sub on_start {
            my $k = $_[KERNEL];
            $_[HEAP]->{nb} = 0;
            $k->delay_set('tick', 1);
            $k->post('IKC', 'subscribe', [ 'poe://my-server/logger/debug' ]);
        }

Une fois souscrit à cet événement, on peut poster des événements de manière transparente de la façon suivante :

        sub on_tick {
            my ($k, $h) = @_[KERNEL, HEAP];

            $k->post('poe://my-server/logger', 'debug', $h->{nb}++ );
            $k->delay_set('tick', 1);
        }

Notre client complet est donc :

        #!/usr/bin/env perl
        use strict;
        use warnings;
        use POE;
        use POE::Component::IKC::Client;

        POE::Component::IKC::Client->spawn( 
            host => 'localhost', 
            port => 17000, 
            name => "client-$$",
            on_connect => \&on_connect,
        );
        POE::Kernel->run();
        exit;


        sub on_connect {
            POE::Session->create(
                inline_states => {
                    _start => \&on_start,
                    tick   => \&on_tick,
                }
            );
        }

        sub on_start {
            my $k = $_[KERNEL];
            $_[HEAP]->{nb} = 0;
            $k->delay_set('tick', 1);
            $k->post('IKC', 'subscribe', [ 'poe://my-server/logger/debug' ]);
        }

        sub on_tick {
            my ($k, $h) = @_[KERNEL, HEAP];
            $k->post('poe://my-server/logger', 'debug', $h->{nb}++ );
            $k->delay_set('tick', 1);
        }

À noter que ce qui passe sur le réseau est automatiquement sérialisé et dé-sérialisé, ce qui fait qu'on peut passer de manière transparente toute structure de donnée évoluée. Cependant, la sérialisation se faisant avec Data::Dumper, l'eval() correspondant peut poser des problèmes de sécurité.

Aller plus loin...

IKC permet beaucoup d'autres choses, dont voici une liste non exhaustive :

Le passage d'événements retours, avec ou sans RSVP (i.e., événement retour différé dans le temps). Intéressant pour avoir un mécanisme de procédures distantes type RPC.
Une communication peer-to-peer pour que le kernel serveur soit à l'origine des communications. Intéressant pour avoir un scheduler qui distribue des tâches à différents clients connectés...
Une surveillance intégrée des kernels distants pour être averti lorsque des kernels se connectent, ou déconnectent, etc.

Mais tout ceci va bien au-delà de cette introduction à POE, et je vous invite à lire la documentation associée à IKC [2] pour découvrir toutes les possibilités offertes.

POE - Perl Object Environment

Chapeau

Principes généraux de POE

Multitâche... coopératif

Ni `fork()`, ni threads.

Événements

Utilisation

Performances

Fonctionnement de POE

Le noyau

Les sessions

Les alias

Différents niveaux d'abstraction

Un peu de pratique...

Hello, world!

Passage de paramètres

Passage de messages

Utilisation avancée

Modulariser le code

POE référence les sessions tout seul

Envoi de messages à soi-même

Remplacement de la heap

Chaque session doit gérer un événement `_start()`

À propos des événements non gérés

Gestion des signaux

Le bon citoyen POE

Interfaces graphiques et POE

POE et les boucles d'événements

Un exemple simple

Ajoutons de l'interactivité

POE distribué

IKC

Logger implémenté en tant que service

Aller plus loin...

Conclusion

Liens

Auteur

POE - Perl Object Environment

Chapeau

Principes généraux de POE

Multitâche... coopératif

Ni fork(), ni threads.

Événements

Utilisation

Performances

Fonctionnement de POE

Le noyau

Les sessions

Les alias

Différents niveaux d'abstraction

Un peu de pratique...

Hello, world!

Passage de paramètres

Passage de messages

Utilisation avancée

Modulariser le code

POE référence les sessions tout seul

Envoi de messages à soi-même

Remplacement de la heap

Chaque session doit gérer un événement _start()

À propos des événements non gérés

Gestion des signaux

Le bon citoyen POE

Interfaces graphiques et POE

POE et les boucles d'événements

Un exemple simple

Ajoutons de l'interactivité

POE distribué

IKC

Logger implémenté en tant que service

Aller plus loin...

Conclusion

Liens

Auteur

Ni `fork()`, ni threads.

Chaque session doit gérer un événement `_start()`