Programmation en PERL

Dans les versions de Perl antérieures à 5.6, toutes les chaînes étaient vues en tant que séquences d'octets. Dans les versions 5.6 et suivantes, une chaîne peut toutefois contenir des caractères d'une taille supérieure à un octet. Nous voyons maintenant les chaînes, non plus en tant que séquences d'octets, mais en tant que séquences de numéros compris dans l'intervalle 0 .. 2**32-1 (ou dans le cas d'ordinateurs 64 bits, 0 .. 2**64-1). Ces numéros représentent des caractères abstraits et, dans un certain sens, plus grand est le numéro, plus la taille du caractère est grande ; mais au contraire de beaucoup de langages, Perl n'est pas lié à une taille particulière de la représentation d'un caractère. Perl utilise un encodage de taille variable (basé sur UTF8), ainsi ces numéros de caractères abstraits peuvent être empaquetés, ou non, à raison d'un numéro par octet. Évidemment, le numéro de caractère 18 446 744 073 709 551 515 (c'est-à-dire, « \x{ffff_ffff_ffff_ffff} ») ne tiendra jamais dans un octet (en fait, il prend 13 octets), mais si tous les caractères de votre chaîne se situent dans l'intervalle 0..127 en décimal, alors ils seront certainement empaquetés à raison d'un par octet, puisque l'UTF8 est identique à l'ASCII pour les sept premiers bits de poids faible.

Perl utilise de l'UTF8 lorsqu'il pense que c'est bénéfique, ainsi, si tous les caractères de votre chaîne sont dans l'intervalle 0..255, il y a une grande chance que les caractères soient empaquetés dans des octets — mais en l'absence d'autres informations connues, vous ne pouvez être sûr, car Perl fait en interne une conversion entre les caractères 8 bits et les caractères UTF8 de taille variable si nécessaire. L'essentiel est que vous ne devriez pas vous en soucier la plupart du temps, car la sémantique de caractère est préservée à un niveau abstrait indépendamment de la représentation.

Dans tous les cas, si votre chaîne contient des numéros de caractères supérieurs à 255 en décimal, la chaîne est certainement stockée en UTF8. Plus exactement, elle est stockée dans la version étendue d'UTF8 de Perl que nous appelons utf8, en hommage au pragma du même nom, mais surtout parce que c'est plus simple à taper. (Et de plus, l'UTF8 « réel » n'est autorisé à contenir que des numéros de caractères consacrés par le Consortium Unicode. L'utf8 de Perl est autorisé à contenir tous les caractères dont vous avez besoin pour accomplir votre travail. Perl se moque du fait que vos numéros de caractères soient officiellement corrects ou juste corrects.)

Nous avons dit que vous ne devriez pas vous en soucier la plupart du temps, mais les gens aiment de toute façon se faire du souci. Supposez que vous ayez une v-chaîne représentant une adresse IPv4 :

$adr_loc = v127.0.0.1;     # Sûrement stockée en octets.
$oreilly = v204.148.40.9;  # Pourrait être stockée en octets ou en utf8.
$adr_nok = v2004.148.40.9; # Sûrement stockée en utf8.

Tout le monde peut s'apercevoir que $adr_nok ne marchera pas en tant qu'adresse IP. Il est donc facile de penser que si l'adresse réseau d'O'Reilly est forcée à une représentation UTF8, elle ne marchera plus. Mais les caractères dans la chaîne sont des numéros abstraits, non des octets. Tout ce qui utilise une adresse IPv4, comme la fonction gethostbyaddr, devrait automatiquement forcer les numéros de caractères abstraits à être reconvertis vers une représentation en octets (et échouer avec $adr_nok).

Les interfaces entre Perl et le monde réel doivent s'accommoder des détails de la représentation. Jusqu'à un certain point, les interfaces existantes essaient de faire ce qu'il faut sans que vous ayez à leur dire quoi faire. Mais de temps en temps, vous devez donner des instructions à certaines interfaces (comme la fonction open) et si vous écrivez votre propre interface vers le monde réel, elle aura besoin d'être soit assez astucieuse pour arriver à comprendre les choses par elle-même, soit au moins assez élégante pour suivre les instructions lorsque vous voulez qu'elle se comporte différemment de ce qu'elle aurait fait par défaut.(125)

Puisque Perl se soucie de maintenir une sémantique de caractère transparente à l'intérieur du langage lui-même, la seule place où vous devez vous inquiéter d'une sémantique d'octet, opposée à une sémantique de caractère, est dans vos interfaces. Par défaut, toutes vos anciennes interfaces Perl vers le monde extérieur sont orientées octet. C'est-à-dire qu'à un niveau abstrait, toutes vos chaînes sont des séquences de numéros dans l'intervalle 0..255, ainsi, si rien dans le programme ne les force à des représentations en utf8, vos anciens programmes continueront à fonctionner avec des données orientées octet comme ils le faisaient auparavant. Vous pouvez donc cocher l'objectif n° 1 ci-dessus.

Si vous voulez que vos anciens programmes fonctionnent avec les nouvelles données orientées caractère, vous devez marquer vos interfaces orientées caractère de manière que Perl s'attende à recevoir des données orientées caractère de ces interfaces. Une fois que c'est fait, Perl devrait automatiquement faire toutes les conversions nécessaires pour préserver l'abstraction des caractères. La seule différence est que vous devez introduire dans votre programme des chaînes qui soient marquées comme contenant potentiellement des caractères plus grands que 255, ainsi, si vous effectuez une opération entre une chaîne d'octets et une chaîne utf8, Perl convertira en interne la chaîne d'octets en une chaîne utf8 avant d'effectuer l'opération. Généralement, les chaînes utf8 ne sont reconverties en chaînes d'octets que lorsque vous les envoyez à une interface orientée octet, auquel cas, si vous aviez une chaîne contenant des caractères plus grands que 255, vous aurez un problème qui peut être résolu de diverses manières selon l'interface en question. Vous pouvez donc cocher l'objectif n° 2.

Parfois, vous voulez mélanger du code comprenant une sémantique de caractère avec du code devant tourner avec une sémantique d'octet, comme du code d'entrées/sorties qui lit ou écrit des blocs de taille fixe. Dans ce cas, vous pouvez mettre une déclaration use bytes autour du code orienté octet pour le forcer à utiliser une sémantique d'octet même sur les chaînes marquées en tant que chaînes utf8. Les conversions sont alors sous votre responsabilité. Mais c'est un moyen de renforcer une lecture locale plus stricte de l'objectif n° 1, aux dépens d'une lecture globale plus relâchée de l'objectif n° 2.

L'objectif n° 3 a largement été atteint, en partie en faisant des conversions paresseuses entre les représentations en octets et en utf8 et en partie en étant discret sur la manière dont nous avons implémenté potentiellement des fonctionnalités lentes d'Unicode, comme la recherche des propriétés de caractères dans des tables énormes.

L'objectif n° 4 a été atteint en sacrifiant un peu de la compatibilité des interfaces à la quête des autres objectifs. D'une certaine façon, nous n'avons pas bifurqué vers deux Perl différents ; mais en le considérant d'une autre manière, la révision 5.6 de Perl est une version bifurquée de Perl au regard des versions antérieures et nous ne nous attendons pas à ce que les gens migrent depuis leurs versions antérieures avant d'être sûrs que la nouvelle version fera bien ce qu'ils veulent. Mais c'est toujours le cas avec les nouvelles versions, nous nous permettrons donc de cocher également l'objectif n° 4.

Le résultat de tout ceci est qu'un opérateur interne typique manipulera des caractères sauf s'il est dans la portée d'un pragma use bytes. Toutefois, même en dehors de la portée d'un use bytes, si tous les opérandes de l'opérateur sont stockés en tant que caractères 8 bits (c'est-à-dire qu'aucun opérande n'est stocké en tant qu'utf8), alors la sémantique de caractère se confond avec la sémantique d'octet et le résultat de l'opérateur sera stocké en interne dans un format 8 bits. Ceci préserve une compatibilité antérieure pourvu que vous n'approvisionniez pas vos programmes avec des caractères plus larges qu'en Latin-1.

Le pragma utf8 est avant tout un dispositif de compatibilité permettant la reconnaissance de l'UTF8 dans les littéraux et les identificateurs rencontrés par l'analyseur grammatical. Il peut également être utilisé pour permettre certaines fonctionnalités des plus expérimentales d'Unicode. Notre objectif à long terme est de changer le pragma utf8 en une opération ne faisant rien (no-op).

Le pragma use bytes ne sera jamais changé en une opération ne faisant rien. Non seulement il est nécessaire pour le code orienté octet, mais un de ses effets de bords est également de définir des enrobages orientés octet autour de certaines fonctions pour les utiliser en dehors d'une portée de use bytes. Au moment où nous écrivons ceci, le seul enrobage défini est pour la fonction, length mais d'autres sont susceptibles de l'être au fil du temps. Pour utiliser cet enrobage, écrivez :

use bytes (); # Charge les enrobages sans importer la sémantique d'octet.
...
$lg_car = length("\x{ffff_ffff}");               # Renvoie 1.
$lg_oct = bytes::length("\x{ffff_ffff}"); # Renvoie 7.

En dehors de la portée d'une déclaration use bytes, la version 5.6 de Perl fonctionne (ou du moins, est censée fonctionner) ainsi :

• Les chaînes et les motifs peuvent maintenant contenir des caractères ayant une valeur ordinale supérieure à 255 :

use utf8;
$convergence = "☞ ☜";

• En supposant que vous ayez un éditeur compatible avec Unicode pour éditer votre programme, de tels caractères se présenteront généralement directement à l'intérieur de chaînes littérales en tant que caractères UTF8. Pour le moment, vous devez déclarer un use utf8 au début de votre programme pour permettre l'utilisation de l'UTF8 dans les littéraux.
  Si vous ne disposez pas d'éditeur Unicode, vous pouvez toujours spécifier un caractère particulier en ASCII avec une extension de la notation \x. Un caractère dans l'intervalle Latin-1 peut être écrit comme \x{ab} ou comme, \xab mais si le numéro dépasse les deux chiffres hexadécimaux, vous devez utiliser des accolades. Les caractères Unicode sont spécifiés en mettant le code hexadécimal à l'intérieur des accolades après le \x. Par exemple, un smiley Unicode vaut \x{263A}. Il n'y a pas de construction syntaxique en Perl présumant que les caractères Unicode fassent exactement 16 bits, vous ne pouvez donc pas utiliser \u263A comme dans certains langages ; \x{263A} est l'équivalent le plus proche.
  Pour insérer des caractères nommés via \N{NOM_CAR}, voir le pragma use charnames au chapitre 31, Modules de pragmas.

• Les identificateurs à l'intérieur du script Perl peuvent contenir des caractères Unicode alphanumériques, y compris des idéogrammes :

   

  Sélectionnez

  use utf8;
  $⋏++; # Un enfant est né.

• Ici encore, use utf8 est nécessaire (pour l'instant) pour reconnaître de l'UTF8 dans votre script. Vous êtes actuellement livré à vous-même lorsqu'il s'agit d'utiliser les formes canoniques des caractères — Perl ne tente pas (encore) de canoniser pour vous les noms de variable. Voir www.unicode.org pour le dernier rapport sur la canonisation.

• Les expressions régulières correspondent à des caractères au lieu d'octets. Par exemple un point correspond à un caractère au lieu de correspondre à un octet. Si le Consortium Unicode arrive même à approuver l'emploi du twengar, alors (malgré le fait que de tels caractères sont représentés avec 4 octets en UTF8), ceci réussit la correspondance :

   

  Sélectionnez

  "\N{TENGWAR LETTER SILME NUQUERNA}" =~ /^.$/

• Le motif \C est fourni pour forcer une correspondance à un seul octet (« char » en C, d'où \C). Utilisez \C avec prudence, puisqu'il peut désynchroniser des caractères dans votre chaîne et vous pouvez obtenir des erreurs « Caractère UTF8 mal formé ». Vous ne pouvez pas utiliser \C dans des crochets, puisqu'il ne représente aucun caractère particulier ni aucun ensemble de caractères.

• Les classes de caractères dans les expressions régulières correspondent à des caractères au lieu d'octets et correspondent avec les propriétés des caractères spécifiées dans la base de données des propriétés Unicode. Ainsi, \w peut être utilisé pour correspondre à un idéogramme :

"⋏" =~ /\w/;

• Les propriétés nommées d'Unicode et les intervalles de blocs peuvent être utilisés comme classes de caractères avec les nouvelles constructions \p (correspond à la propriété) et \P (ne correspond pas à la propriété). Par exemple, \p{Lu} correspond à tout caractère ayant la propriété majuscule d'Unicode, alors que \p{M} correspond à tout caractère marqué. Les propriétés d'une seule lettre peuvent omettre les accolades, ainsi \pM peut également correspondre à des caractères marqués. Beaucoup de classes de caractères prédéfinies sont disponibles, comme \p{IsMirrored} et \p{InTibetan} :

   

  Sélectionnez

  "\N{greek:Iota}" =~ /p{Lu}/

• Vous pouvez également utiliser \p et \P à l'intérieur des crochets des classes de caractères. (Dans la version 5.6.0 de Perl, vous avez besoin de faire use utf8 pour que les propriétés des caractères fonctionnent bien. Cette restriction sera levée à l'avenir.) Voir le chapitre 5, Correspondance de motifs, pour plus de détails sur la correspondance de propriétés Unicode.

• Le motif spécial \X correspond à toute séquence Unicode étendue (une « séquence de caractères combinés » en langage standard), où le premier caractère est un caractère de base et les suivants des caractères marqués s'appliquant au caractère de base. C'est équivalent à (?:\PM\pM*) :

   

  Sélectionnez

  "o\N{COMBINING TILDE BELOW}" =~ /\X/

• Vous ne pouvez pas utiliser \X à l'intérieur de crochets, car il pourrait correspondre à plusieurs caractères et il ne représente aucun caractère particulier ni aucun ensemble de caractères.

• L'opérateur tr/// traduit des caractères au lieu d'octets. Pour changer tous les caractères hors de l'intervalle Latin-1 en points d'interrogation, vous pourriez écrire :

   

  Sélectionnez

  tr/\0-\x{10ffff}/\0-\xff?/; # caractère utf8 vers latin1

• Les opérateurs de traduction de casse utilisent des tables de traduction de casse Unicode lorsqu'on leur fournit des caractères en entrée. Remarquer que uc traduit en majuscules, alors qu'ucfisrt traduit l'initiale en majuscule de titre (titlecase), pour les langues qui font la distinction. Naturellement les séquences d'antislashs correspondantes ont la même sémantique :

   

  Sélectionnez

  $x = "\u$mot";  # met l'initiale de $mot en majuscule de titre
  $x = "\U$mot";  # met $mot en majuscules
  $x = "\l$mot";  # met l'initiale de $mot en minuscule
  $x = "\L$mot";  # met $mot en minuscules

  Soyez prudent, car les tables de traduction de casse Unicode ne tentent pas de fournir des tables de correspondance bijectives pour chaque instance, particulièrement pour les langues utilisant un nombre de caractères différent pour les majuscules et les minuscules. Comme ils disent dans les standards, alors que les propriétés de casse sont elles-mêmes normatives, les tables de casse ne sont qu'informelles.

• La plupart des opérateurs manipulant des positions ou des longueurs dans une chaîne basculeront automatiquement à l'utilisation de positions de caractères, ce qui comprend : chop, substr, pos, index, rindex, sprintf, write et length. Les opérateurs qui ne basculent pas délibérément comprennent vec, pack et unpack. Les opérateurs qui s'en moquent vraiment comprennent chomp, ainsi que tout autre opérateur traitant une chaîne comme un paquet de bits, tels que le sort par défaut et les opérateurs manipulant des fichiers.

   

  Sélectionnez

  use bytes;
  $lg_octets = length("Je fais de l'合 氣 道"); # 15 octets
  no bytes;
  $lg_caracs = length("Je fais de l'合 氣 道"); # mais 9 caractères

• Les lettres « c » et « C » de pack/unpack ne changent pas, puisqu'elles sont souvent utilisées pour des formats orientés octet. (Encore une fois, pensez « char » en langage C.) Toutefois, il existe un nouveau spécificateur « U », qui fera les conversions entre les caractères UTF8 et les entiers :

   

  Sélectionnez

  pack("U*", 1, 20, 300, 4000) eq v1.20.300.4000

• Les fonctions chr et ord fonctionnent avec des caractères :

   

  Sélectionnez

  chr(1).chr(20).chr(300).chr(4000) eq v1.20.300.4000

• En d'autres termes, chr et ord sont comme pack("U") et unpack("U") et non comme pack("C") et unpack("C"). En fait, ces derniers sont un moyen pour vous d'émuler les fonctions chr et ord orientées octet si vous êtes trop paresseux pour faire un use bytes.

• Enfin, un reverse en contexte scalaire inverse par caractère plutôt que par octet :

"☞ ☜" eq reverse "☜ ☞"

Si vous regardez dans le répertoire CHEMIN_BIBLIOTHEQUE_PERL/unicode, vous trouverez de nombreux fichiers en rapport avec la définition des sémantiques ci-dessus. La base de données des propriétés Unicode provenant du Consortium Unicode se situe dans un fichier appelé Unicode.300 (pour Unicode 3.0). Ce fichier a déjà été traité par mktables.PL pour donner un tas de petits fichiers .pl dans le même répertoire (et dans les sous-répertoires Is/, In/ et To/), dont certains sont automatiquement avalés par Perl pour implémenter des choses comme \p (voir les répertoires Is/ et In/) et uc (voir le répertoire To/). Les autres fichiers sont avalés par des modules comme le pragma use charnames (voir Name.pl). Mais au moment où nous écrivons ceci, il reste encore de nombreux fichiers qui sont juste assis là sans rien faire, en attendant que vous leur écriviez un module d'accès :

• ArabLink.pl
• ArabLnkGrp.pl
• Bidirectional.pl
• Block.pl
• Category.pl
• CombiningClass.pl
• Decomposition.pl
• JamoShort.pl
• Number.pl
• To/Digit.pl

Un résumé bien plus lisible d'Unicode, avec beaucoup de liens hypertextes, se trouve dans CHEMIN_BIBLIOTHEQUE_PERL/unicode/Unicode3.html.

Remarquez que lorsque le Consortium Unicode sort une nouvelle version, certains de ces noms de fichier sont susceptibles de changer, vous devrez donc fouiller un peu. Vous pouvez trouver CHEMIN_BIBLIOTHEQUE_PERL avec l'incantation suivante :

% perl -MConfig -le 'print $Config{privlib}'

Pour trouver tout ce que l'on peut trouver sur Unicode, vous devriez consulter The Unicode Standard Version 3.0 (ISBN 0-201-61633-5).

Au moment où nous écrivons ceci (c'est-à-dire, en phase avec la version 5.6.0 de Perl), il existe encore des précautions à prendre pour utiliser Unicode. (Consultez votre documentation en ligne pour les mises à jour.)

• Le compilateur d'expressions régulières existant ne produit pas de codes d'opérations (opcodes) polymorphiques. Cela signifie que le fait de déterminer si un motif particulier correspondra ou non à des caractères Unicode est réalisé lorsque le motif est compilé (basé sur le fait que le motif contient ou non des caractères Unicode) et non lorsque la correspondance arrive à l'exécution. Ceci doit être changé pour correspondre de manière adaptée à de l'Unicode si la chaîne sur laquelle se fait la correspondance est en Unicode.
• Il n'y a actuellement pas de moyen facile de marquer une donnée lue depuis un fichier ou depuis toute autre source externe comme étant en utf8. Ceci sera un domaine sur lequel se concentrer dans un futur proche et ce sera probablement déjà corrigé au moment où vous lirez ceci.
• Il n'y a pas de méthode pour forcer automatiquement l'entrée et la sortie vers d'autres encodages que UTF8. Ceci est toutefois prévu dans un futur proche, consultez donc votre documentation en ligne.
• L'utilisation de locales avec utf8 peut conduire à d'étranges résultats. Actuellement, il existe quelques tentatives pour appliquer l' information d'une locale 8 bits à des caractères dans l'intervalle, 0..255 mais ceci est de façon évidente incorrect pour des locales qui utilisent des caractères au-delà de cet intervalle (lorsqu'ils sont convertis en Unicode). Cela aura également tendance à tourner plus lentement. Le bannissement des locales est fortement encouragé.

L'Unicode est « fun » — il faut juste que vous définissiez le fun correctement.

Perl utilise un modèle simple de gestion des signaux : le hachage %SIG contient des références (qu'elles soient symboliques ou en dur) à des gestionnaires de signaux définis par l'utilisateur. Certains événements entraînent le système d'exploitation à délivrer un signal au processus affecté. Le gestionnaire correspondant à cet événement est appelé avec un argument contenant le nom du signal qui l'a déclenché. Pour envoyer un signal à un autre processus, utilisez la fonction kill. Pensez-y comme à une information d'un bit envoyée à l'autre processus.(127) Si ce processus a installé un gestionnaire de signal pour le signal en question, il peut exécuter du code lorsqu'il le reçoit. Mais il n'y a aucun moyen pour le processus émetteur d'obtenir une quelconque sorte de valeur de retour, autre que de savoir si le signal a été légitimement envoyé. L'émetteur ne reçoit aucun retour lui disant ce que le processus récepteur a fait du signal, s'il en a fait quelque chose.

Nous avons classé cette fonctionnalité dans les IPC alors qu'en fait, les signaux peuvent provenir de diverses sources et pas seulement d'autres processus. Le signal pourrait également provenir du même processus, ou bien il pourrait être généré lorsque l'utilisateur tape au clavier une séquence particulière comme Ctrl-C ou Ctrl-Z, ou il pourrait être fabriqué par le noyau quand certains événements se produisent, comme la fin d'un processus fils, ou lorsque le processus n'a plus assez d'espace sur la pile, ou parce qu'un fichier a atteint sa taille limite en mémoire. Mais votre propre processus ne sait pas distinguer facilement ces différents cas. Un signal ressemble à un paquet qui arrive mystérieusement sur le pas de la porte sans l'adresse de l'expéditeur. Vous feriez mieux d'être prudent au moment de l'ouvrir.

Puisque les entrées dans le hachage %SIG peuvent être des références en dur, une technique courante est d'utiliser des fonctions anonymes pour les gestionnaires de signaux simples :

$SIG{INT}  = sub { die "\nIci\n" };
$SIG{ALRM} = sub { die "Votre minuterie a expiré" };

Ou vous pourriez créer une fonction nommée et affecter son nom ou une référence à l'entrée appropriée du hachage. Par exemple, pour intercepter les signaux d'interruption et de sortie (souvent associés aux touches Ctrl-C et Ctrl-\ sur votre clavier), mettez en place un gestionnaire comme ceci :

sub intercepte {
    my $nom_sig = shift;
    our $ben_voyons++;
    die "Quelqu'un m'a envoyé un SIG$nom_sig !";
}
$ben_voyons = 0;
$SIG{INT} = 'intercepte';  # signifie toujours &main::intercepte
$SIG{INT} = \&intercepte;  # la meilleure stratégie
$SIG{QUIT} = \&intercepte; # en intercepte également un autre

Remarquez que tout ce que nous faisons dans le gestionnaire de signaux est de positionner une variable globale et de lever une exception avec die. Évitez autant que possible de faire quelque chose de plus compliqué que cela, car sur la plupart des systèmes, la bibliothèque C n'est pas réentrante. Les signaux sont délivrés de manière asynchrone,(128) ainsi, l'appel à une quelconque fonction print (voire à tout ce qui a besoin d'allouer plus de mémoire avec malloc(3)) pourrait en théorie déclencher une erreur de mémoire et engendrer un core dump si vous étiez déjà dans une routine apparentée de la bibliothèque C lorsque le signal a été délivré. (Même la routine die est quelque peu dangereuse sauf si le processus est exécuté à l'intérieur d'un eval, ce qui supprime les entrées/ sorties depuis die et par conséquent empêche d'appeler la bibliothèque C. Probablement.)

Une manière encore plus simple d'intercepter les signaux est d'utiliser le pragma sigtrap pour installer de simples gestionnaires de signaux par défaut :

use sigtrap qw(die INT QUIT);
use sigtrap qw(die untrapped normal-signals
    stack-trace any error-signals);

Le pragma est très utile lorsque vous ne voulez pas vous embêter à écrire votre propre gestionnaire, mais que vous voulez toujours intercepter les signaux dangereux et tout fermer dans les règles. Par défaut, certains de ces signaux ont un caractère si fatal pour votre processus que votre programme s'arrêtera en pleine course lorsqu'il en recevra un. Malheureusement, cela signifie que les fonctions END gérant la terminaison du programme et les méthodes DESTROY s'occupant de l'achèvement d'un objet ne seront pas appelées. Mais elles le seront sur des exceptions Perl ordinaires (comme lorsque vous appelez die), vous pouvez donc utiliser ce pragma pour convertir sans douleur les signaux en exceptions. Même si vous ne manipulez pas de signaux vous-même, votre programme devra bien se comporter quand même. Voir la description de use sigtrap au Chapitre 31, Modules de pragmas, pour beaucoup plus de fonctionnalités de ce pragma.

Vous pouvez également choisir d'affecter au gestionnaire de %SIG les chaînes « IGNORE » ou « DEFAULT », auquel cas Perl essayera d'écarter le signal ou permettra que se produise l'action par défaut pour ce signal (bien que certains signaux ne peuvent être ni interceptés ni ignorés, comme les signaux KILL et STOP ; voir signal(3), s'il est implémenté, pour obtenir une liste des signaux disponibles sur votre système et leur comportement par défaut.

Le système d'exploitation voit les signaux comme des nombres plutôt que comme des noms, mais Perl, comme la plupart des gens, préfère les noms symboliques aux nombres magiques. Pour trouver les noms des signaux, passez en revue les clefs du hachage %SIG ou utilisez la commande kill -l si vous en disposez sur votre système. Vous pouvez également utiliser le module standard Config pour déterminer la correspondance que fait votre système entre les noms et les numéros des signaux. Voir Config(3) pour des exemples.

Puisque %SIG est un hachage global, les affections que vous y effectuez se répercutent sur tout votre programme. Il est souvent plus respectueux pour le reste de votre programme de confiner l'interception des signaux à une portée réduite. Faites cela avec une affectation en local du gestionnaire de signaux, ce qui n'a plus d'effet une fois que l'on sort du bloc l'encadrant. (Mais souvenez-vous que les valeurs avec local sont visibles depuis les fonctions appelées depuis ce bloc.)

{
    local $SIG{INT} = 'IGNORE';
    ...     # Faites ce que vous voulez ici, en ignorant tous les SIGINT.
    fn();   # Les SIGINT sont également ignorés dans fn() !
    ...     # Et ici.
}           # La fin du bloc restaure la valeur précédente de $SIG{INT}.
fn();       # Les SIGINT ne sont pas ignorés dans fn() (a priori).

16-1-a. Envoi de signaux à des groupes de processus▲

{
    local $SIG{HUP} = 'IGNORE';   # m'exempte
    kill(HUP, -$$);               # envoie le signal à mon propre
                                  # groupe de processus
}

unless (kill 0 => $pid_fils) {
    warn "quelque chose d'affreux est arrivé à $pid_fils";
}

16-1-b. Fossoyage des zombies▲

use POSIX ":queue";
sub FOSSOYEUR { 1 until (waitpid(-1, WNOHANG) == -1) }

$SIG{CHLD} = \&FOSSOYEUR;

our $zombies = 0;
$SIG{CHLD} = sub { $zombies++ };
sub fossoyeur {
    my $zombie;
    our %Statut_Fils; # Stocke chaque code de retour
    $zombies = 0;
    while (($zombie = waitpid(-1, WNOHANG)) != -1) {
        $Statut_Fils{$zombie} = $?;
    }
}
while (1) {
    fossoyeur() if $zombies;
    ...
}

16-1-c. Minutage des opérations lentes▲

use Fcntl ':flock';
eval {
    local $SIG{ALRM} = sub { die "redémarrage de la minuterie" };
    alarm 10;              # planifie une alarme dans 10 secondes
    eval {
        flock(HF, LOCK_EX) # un verrou exclusif bloquant
            or die "flock impossible : $!";
    };
    alarm 0;               # annule l'alarme
};
alarm 0;            # protection contre une situation de concurrence
die if $@ && $@ !~ /redémarrage de la minuterie/;     # relance

16-1-d. Blocage des signaux▲

use POSIX qw(:signal_h);
$ensemble_signaux = POSIX::SigSet->new;
$ensemble_bloques = POSIX::SigSet>new(SIGINT,SIGQUIT,SIGCHLD);
sigprocmask(SIG_BLOCK, $ensemble_bloques, $ensemble_signaux)
    or die "Impossible de bloquer les signaux INT,QUIT,CHLD : $!\n";

sigprocmask(SIG_SETMASK, $ensemble_signaux)
    or die "Impossible de restaurer les signaux INT, QUIT, CHLD: $!\n";

Peut-être n'aviez-vous jamais pensé aux fichiers comme étant un mécanisme d'IPC, mais ils se taillent la part du lion dans les communications interprocessus — loin devant tous les autres procédés réunis. Lorsqu'un processus dépose ses précieuses données dans un fichier et qu'un autre processus les extrait, ces processus ont communiqué entre eux. Les fichiers offrent quelque chose d'unique parmi toutes les formes d'IPC couvertes ici : comme un rouleau de papyrus enseveli dans le désert et déterré après des millénaires, un fichier peut être déterré et lu longtemps après le décès de celui qui l'a écrit.(131) En travaillant sur la persistance tout en étant d'une facilité d'utilisation comparable, il n'est pas surprenant que les fichiers soient toujours populaires.

L'emploi de fichiers, pour transmettre des informations depuis un passé révolu vers un futur incertain, amène quelques surprises. Vous écrivez le fichier sur un médium permanent, tel qu'un disque, et c'est tout. (Vous pourriez dire à un serveur web où le trouver, s'il contient du HTML.) Cela devient un challenge intéressant lorsque tous les protagonistes sont toujours en vie et essaient de communiquer entre eux. Sans une convention à propos de celui dont le temps de parole est arrivé, toute communication fiable est impossible ; l'accord peut être conclu via le verrouillage de fichier, qui sera abordé dans le prochain paragraphe. Dans le paragraphe suivant, nous parlerons de la relation spéciale existant entre un processus père et ses fils, qui permet à toutes les protagonistes d'échanger de l'information via l'héritage de l'accès aux mêmes fichiers.

Les fichiers présentent toutefois des limites quand il est question d'accès distant, de synchronisation, de fiabilité et de suivi des sessions. D'autres paragraphes de ce chapitre présentent divers mécanismes d'IPC inventés pour pallier ces limites.

16-2-a. Verrouillage de fichier▲

use Fcntl qw(:DEFAULT :flock);
open(HF, "< nom_fichier") or die "impossible d'ouvrir nom_fichier: $!";
flock(HF, LOCK_SH) or die "impossible de verrouiller nom_fichier : $!";
# maintenant, lisez le fichier

flock(HF, LOCK_SH | LOCK_NB)
    or die "impossible de verrouiller nom_fichier : $!";

use Fcntl qw(:DEFAULT :flock);
open(HF, "< nom_fichier") or die "impossible d'ouvrir nom_fichier: $!";
unless (flock(HF, LOCK_SH | LOCK_NB)) {
    local $| = 1;
    print "Attente d'un verrou sur nom_fichier...";
    flock(HF, LOCK_SH)
        or die "impossible de verrouiller nom_fichier : $!";
    print "obtenu.\n";
}
# maintenant, lisez dans HF

use Fcntl qw(:DEFAULT :flock);
sysopen(HF, "nom_fichier", O_WRONLY | O_CREAT)
    or die "impossible d'ouvrir nom_fichier : $!";
flock(HF, LOCK_EX)
    or die "impossible de verrouiller nom_fichier : $!";
truncate(HF, 0)
    or die "impossible de tronquer nom_fichier : $!";
# maintenant, écrivez dans HF

use Fcntl qw(:DEFAULT :flock);

sysopen(HF, "fichier_compteur", O_RDWR | O_CREAT)
    or die "impossible d'ouvrir fichier_compteur : $!";
flock(HF, LOCK_EX)
    or die "impossible de verrouiller en écriture fichier_compteur : $!";
$compteur = <HF> || 0; # serait indéfini la première fois
seek(HF, 0, 0)
    or die "impossible de rembobiner fichier_compteur : $!";
print HF $compteur+1, "\n"
    or die "impossible d'écrire dans fichier_compteur : $!";

# la prochaine ligne est superflue dans ce programme
#, mais est une bonne idée dans le cas général
truncate(HF, tell(HF))
    or die "impossible de tronquer fichier_compteur : $!";
close(HF)
    or die "impossible de fermer fichier_compteur : $!";

use Fcntl qw(:DEFAULT :flock);
use DB_File; # seulement pour l'exemple; toute autre db convient

$NOM_DB = "chemin/a/la/base";
$VERROU = $NOM_DB . ".verrou";

# utilisez O_RDWR si vous pensez mettre des données dans le fichier verrou
sysopen(DB_VER, $VERROU, O_RDONLY | O_CREAT)
     or die "impossible d'ouvrir $VERROU : $!";

# vous devez obtenir le verrou avant d'ouvrir la base
flock(DB_VER, LOCK_SH)
    or die "impossible de verrouiller $VERROU avec LOCK_SH : $!";

tie(%hachage, "DB_File", $NOM_DB, O_RDWR | O_CREAT)
    or die "impossible de lier $NOM_DB : $!";

untie %hachage;   # vous devez fermer la base avant le fichier verrou
close DB_VER;     # maintenant le verrou peut partir en toute sécurité

16-2-b. Passage de handles de fichiers▲

open(ENTREE, "< /etc/motd") or die "/etc/motd : $!";
if ($pid = fork) { waitpid($pid, 0) }
else {
    defined($pid) or die "fork : $!";
    while (<ENTREE>) { print "$. : $_" }
    exit; # empêche le fils de retomber dans le code principal
}
# le handle de fichier ENTREE se trouve maintenant à EOF pour le père

open(ENTREE, "< /etc/motd")    or die "/etc/motd : $!";
if ($pid = fork) { wait }
else {
    defined($pid)              or die "fork : $!";
    open(STDIN, "<&ENTREE")    or die "dup : $!";
    exec("cat", "-n")          or die "exec cat : $!";
}

# ouvre le fichier et marque ENTREE comme devant être
# conservé entre les exec
{
    local $^F = 10_000;
    open(ENTREE, "< /etc/motd") or die "/etc/motd : $!";
} # l'ancienne valeur de $^F est restaurée lorsqu'on sort de la portée

if ($pid = fork) { wait }
else {
    defined($pid)                    or die "fork : $!";
    $fichier_df = "/dev/fd/" . fileno(ENTREE);
    exec("cat", "-n", $fichier_df)   or die "exec cat : $!";
}

use Fcntl qw/F_SETFD/;

fcntl(ENTREE, F_SETFD, 0)
    or die "Impossible de mettre à zéro le flag close-on-exec
        pour ENTREE : $!\n";

fcntl(ENTREE, F_SETFD, 1)
    or die "Impossible de positionner le flag close-on-exec
        pour ENTREE : $!\n";

use Fcntl qw/F_SETFD F_GETFD/;

printf("ENTREE sera %s entre les exec\n",
    fcntl(ENTREE, F_GETFD, 1) ? "fermé" : "laissé ouvert");

if (defined($ENV{no_df_entree}) && $ENV{no_df_entree} =~ /^d$/) {
    open(ENTREE, "<&=$ENV{no_df_entree}")
        or die "fdopen $ENV{no_df_entree} en entrée impossible : $!";
}

#!/usr/bin/perl -p
# nl -numéro de lignes en entrée
printf "%6d ", $.;

$df_spec = '<&=' . fileno(ENTREE);
system("nl", $df_spec);

@lignes = `nl '$df_spec'`;   # les apostrophes empêchent le
                             # shell d'interpoler df_spec

Un pipe est un canal d'entrées/sorties unidirectionnel pouvant transférer un flux d'octets d'un processus à un autre. Il existe deux variétés de pipes : les pipes nommés et les pipes anonymes. Il se peut que vous connaissiez mieux les pipes anonymes, dont nous commencerons donc par parler.

16-3-a. Pipes anonymes▲

open IMPRESSION, "| cat -v | lpr -h 2>/dev/null"
    or die "fork impossible : $!";
local $SIG{PIPE} = sub { die "pipe d'impression cassé" };
print IMPRESSION "trucs\n";
close IMPRESSION or die "mauvaise impression : $! $?";

open IMPRESSION, "|-", "lpr", "-h" # exige Perl 5.6.1
    or die "impossible de lancer lpr : $!";

if (-t STDOUT) {     # seulement si stdout est un terminal
    my $pager = $ENV{PAGER} || 'more';
    open(STDOUT, "| $pager")  or die "fork du pager impossible : $!";
}
END {
    close(STDOUT)             or die "impossible de fermer STDOUT : $!"
}

open STATUT, "netstat -an 2>/dev/null |"
    or die "fork impossible : $!";
while (<STATUT>) {
    next if /^(tcp|udp)/;
    print;
}
close STATUT or die "mauvais netstat: $! $?";

open STATUT, "-|", "netstat", "-an" # exige Perl 5.6.1
    or die "impossible de lancer netstat : $!";

print grep { !/^(tcp|udp)/ } `netstat -an 2>&1`;
die "mauvais netstat" if $?;

16-3-b. Soliloque▲

if (open(VERS, "|-")) {
    print VERS $depuis_pere;
}
else {
    $vers_fils = <STDIN>;
    exit;
}

if (open(DEPUIS, "-|"))
    $vers_pere = <DEPUIS>;
}
else {
    print STDOUT $depuis_fils;
    exit;
}

tee("/tmp/truc", "/tmp/machin", "/tmp/bidule");

while (<>) {
    print "$ARGV à la ligne $. => $_";
}
close(STDOUT) or die "impossible de fermer STDOUT : $!";

sub tee {
    my @sortie = @_;
    my @handles = ();
    for my $chemin (@sortie) {
        my $hf; # open remplira ceci
        unless (open ($hf, ">", $chemin)) {
            warn "impossible d'écrire dans $chemin : $!";
            next;
        }
        push @handles, $hf;
    }
    # rouvre STDOUT dans le père et renvoie
    return if my $pid = open(STDOUT, "|-");
    die "fork impossible : $!" unless defined $pid;

    # traite STDIN dans le fils
    while (<STDIN>) {
        for my $hf (@handles) {
            print $hf $_ or die "échec de la sortie de tee : $!";
        }
    }
    for my $hf (@handles) {
        close($hf) or die "échec de la fermeture de tee : $!";
    }
    exit; # empêche le fils de renvoyer au programme principal !
}

fonction_mechante("arg");        # zut, ça nous a échappé !
$chaine = sub_fork(\&fonction_mechante, "arg"); # capturez-la dans une
                                                # chaîne
@lignes = sub_fork(\&fonction_mechante, "arg"); # dans des lignes séparées

sub sub_fork {
    my $pid_fils = open my $self, "-|";
    defined $pid_fils   or die "fork impossible : $!";
    shift->(@_), exit   unless $pid_fils;
    local $/            unless wantarray;
    return <$self>;     # ferme à la sortie de la portée
}

16-3-c. Communication bidirectionnelle▲

open(PROG_EN_LECTURE_ECRITURE, "| un programme |")    # MAUVAIS !

Can't do bidirectional pipe at mon_prog line 3.

use IPC::OPen2;
local (*Lecteur, *Ecrivain);
$pid = open2(\*Lecteur, \*Ecrivain, "bc -l");
$somme = 2;
for (1 .. 5) {
    print Ecrivain "$somme * $somme\n";
    chomp($somme = <Lecteur>);
}
close Ecrivain;
close Lecteur;
waitpid($pid, 0);
print "La somme vaut $somme\n";

my ($hf_lecture, $hf_ecriture);
$pid = open2($hf_lecture, $hf_hf_ecriture, "cat -u -n");

pipe(DEPUIS_PERE, VERS_FILS)   or die "pipe : $!";
pipe(DEPUIS_FILS, VERS_PERE)   or die "pipe : $!";
select((select(VERS_FILS), $| = 1))[0]); # vidage automatique
select((select(VERS_PERE), $| = 1))[0]); # vidage automatique

if ($pid = fork) {
    close DEPUIS_PERE; close VERS_PERE;
    print VERS_FILS "Pid $$ du père envoie ceci\n";
    chomp($ligne = <DEPUIS_FILS>);
    print "Pid $$ du père vient de lire ceci : '$ligne'\n";
    close DEPUIS_FILS; close VERS_FILS;
    waitpid($pid,0);
} else {
    die "fork impossible : $!" unless defined $pid;
    close DEPUIS_FILS; close VERS_FILS;
    chomp($ligne = <DEPUIS_PERE>);
    print "Pid $$ du fils vient de lire ceci : '$ligne'\n";
    print VERS_PERE "Pid $$ du fils envoie ceci\n";
    close DEPUIS_PERE; close VERS_PERE;
    exit;
}

use Socket;
socketpair(Fils, Pere, AF_UNIX, SOCK_STREAM, PF_UNSPEC)
    or die "socketpair: $!";
# ou laissez Perl choisir les handles de fichiers pour vous
my ($hf_fils, $hf_pere);
socketpair($hf_fils, $hf_pere, AF_UNIX, SOCK_STREAM, PF_UNSPEC)
    or die "socketpair: $!";

16-3-d. Pipes nommés▲

use Fcntl;               # pour sysopen
chdir;                   # au répertoire « maison »
$chemin_f = '.signature';
$ENV{PATH} .= ":/usr/games";

unless (-p $chemin_f) { # pas un pipe
    if (-e _) {         #, mais quelque chose d'autre
        die "$0 : n'écrasera pas .signature\n";
    } else {
        require POSIX;
        POSIX::mkfifo($chemin_f, 0666)
           or die "mknod $chemin_f impossible: $!";
        warn "$0 : a créé $chemin_f en tant que pipe nommé\n";
    }
}
while (1) {
    # quitte si le fichier signature est supprimé manuellement
    die "Le fichier pipe a disparu" unless -p $chemin_f;
    # la prochaine ligne bloque s'il n'y a pas de lecteur
    sysopen(FIFO, $chemin_f, O_WRONLY)
        or die "Impossible d'écrire dans $chemin_f: $!";
    print FIFO "Gérard Lambert (lambert\@machine.org)\n", `fortune -s`;
    close FIFO;
    select(undef, undef, undef, 0.2); # dort 1/5ème de seconde
}

Tout le monde déteste les IPC System V. Elles sont plus lentes que des cartes perforées, se taillent de petits espaces de noms insidieux sans aucun rapport avec le système de fichiers, utilisent des numéros hostiles à l'entendement humain pour nommer leurs objets et perdent constamment le fil de leurs propres pensées. Et de temps à autre, votre administrateur système doit se lancer dans une opération de ratissage pour rechercher et de détruire ces objets perdus d'IPC SysV avec ipcs(1) et les tuer avec ipcrm(1), avant que le système n'ait plus de mémoire, si tout va bien.

Malgré tous ces maux, les antiques IPC SysV ont toujours des applications valides. Les trois sortes d'objets d'IPC sont la mémoire partagée, les sémaphores et les messages. Pour la transmission de messages, on préférera de nos jours le mécanisme de sockets qui est en outre beaucoup plus portable. Pour les utilisations simples des sémaphores, on a plutôt tendance à utiliser le système de fichiers. Quant à la mémoire partagée — en fait, vous avez maintenant un problème. Si vous l'avez, l'appel système mmap(2), plus moderne, remplit ce contrat(136), mais la qualité de l'implémentation varie d'un système à l'autre. Il requiert en outre un peu d'attention pour que Perl évite de réallouer vos chaînes depuis l'endroit où mmap(2) les a mises. Mais lorsque les programmeurs envisagent d'utiliser mmap(2), ils entendent marmonner de manière incohérente les gourous locaux sur le fait que mmap souffre de problèmes épineux avec la cohérence de cache s'il manque quelque chose appelé un « cache de tampon unifié » (unified buffer cache)—à moins que ce ne soit une « tâche d'unité de canton » ( flycatcher unibus) — et, réfléchissant sur le fait que l'on sait ce qu'on perd, mais qu'on ne sait pas ce qu'on trouve, ils retournent vite aux IPC SysV qu'ils connaissent et détestent pour tous leurs besoins en mémoire partagée.

Voici un petit programme démontrant l'accès contrôlé à un tampon en mémoire partagé par une nichée de processus apparentés. Les objets d'IPC SysV peuvent également être partagés entre des processus sans rapport les uns avec les autres, sur le même ordinateur, mais vous devez alors imaginer comment ils vont se trouver les uns les autres. Nous créerons un sémaphore par entité, qui servira d'intermédiaire pour un accès sécurisé.(137)

À chaque fois que vous voulez récupérer ou mettre une nouvelle valeur en mémoire partagée, vous devez passer d'abord par le sémaphore. Ceci peut devenir un peu pénible, nous enroberons donc l'accès dans une classe d'objets. Le module IPC::Shareable va encore plus loin en enrobant sa classe d'objets dans une interface tie.

Ce programme tourne jusqu'à ce que vous l'interrompiez avec un Ctrl-C ou un équivalent :

#!/usr/bin/perl -w
use v5.6.0;   # ou une version supérieure
use strict;
use sigtrap qw(die INT TERM HUP QUIT);
my $PROGENITURE = shift(@ARGV) || 3;
eval { main() }; # voir DESTROY ci-dessous pour comprendre pourquoi
die if $@ && $@ !~ /^SIG reçu/;
print "\nFini.\n";
exit;

sub main {
    my $mem = ShMem->allouer("Création Originale à " . localtime);
    my(@rejetons, $fils);
    $SIG{CHLD} = 'IGNORE';
    for (my $embryon = $PROGENITURE; $embryon > 0; $embryon--) {
        if ($fils = fork) {
           print "$$ engendra $fils\n";
           next;
        }
        die "fork impossible : $!" unless defined $fils;
        eval {
            while (1) {
                $mem->verrouiller();
                $mem->positionner("$$ " . localtime)
                unless $mem->consulter =~ /^$$\b/o;
                $mem->deverrouiller();
            }
        };
        die if $@ && $@ !~ /^SIG reçu/;
        exit; # mort du fils
    }
    while (1) {
        print "Le tampon vaut ", $mem->recuperer, "\n";
        sleep 1;
    }
}

Et voici le paquetage ShMem, que ce programme utilise. Vous n'avez qu'à l'épingler à la fin du programme ou le mettre dans son propre fichier (avec un « 1; » à la fin) et le charger avec require depuis le programme principal. (On trouve les deux modules d'IPC qu'il utilise à son tour dans la distribution standard de Perl.)

package ShMem;
use IPC::SysV qw(IPC_PRIVATE IPC_RMID IPC_CREAT S_IRWXU);
use IPC::Semaphore;
sub MAXBUF() { 2000 }

sub allouer { # constructeur
    my $classe = shift;
    my $valeur = @_ ? shift : '';

    my $clef = shmget(IPC_PRIVATE, MAXBUF, S_IRWXU) or die "shmget : $!";
    my $sem = IPC::Semaphore->new(IPC_PRIVATE, 1, S_IRWXU | IPC_CREAT)
                        or die "IPC::Semaphore->new : $!";
    $sem->setval(0,1)   or die "sem setval : $!";

    my $obj = bless {
        PROPRIETAIRE => $$,
        SHMKEY => $clef,
        SEMA => $sem,
    } => $classe;

    $obj->mettre($valeur);
    return $obj;
}

Maintenant, passons aux méthodes de collecte et de stockage. Les méthodes recolter et mettre verrouillent le tampon, contrairement aux méthodes consulter et positionner, ces dernières ne devraient donc être utilisées que lorsque l'objet est verrouillé manuellement — ce que vous devez faire lorsque vous voulez aller chercher une ancienne valeur et remettre une version modifiée, tout cela avec le même verrou. Le programme de démonstration fait ceci dans sa boucle while (1). La transaction complète doit se dérouler avec le même verrou sinon le test et le positionnement ne seraient pas atomiques et pourraient exploser.

sub recolter {
    my $obj = shift;
    $obj->verrouiller;
    my $valeur = $obj->consulter(@_);
    $obj->deverrouiller;
    return $valeur;
}
sub consulter {
    my $obj = shift;
    shmread($obj-&>{SHMKEY}, my $tampon='', 0, MAXBUF)
        or die "shmread : $!";
    substr($tampon, index($tampon, "\0")) = '';
    return $tampon;
}
sub mettre {
    my $obj = shift;
    $obj->verrouiller;
    $obj->positionner(@_);
    $obj->deverrouiller;
}
sub positionner {
    my($obj,$msg) = @_;
    shmwrite($obj->{SHMKEY}, $msg, 0, MAXBUF) or die "shmwrite : $!";
}
sub verrouiller {
    my $obj = shift;
    $obj->{SEMA}->op(0,-1,0) or die "semop : $!";
}
sub deverrouiller {
    my $obj = shift;
    $obj->{SEMA}->op(0,1,0) or die "semop : $!";
}

Finalement, la classe a besoin d'un destructeur pour que, lorsque l'objet disparaît, nous puissions manuellement désallouer la mémoire partagée et le sémaphore stocké à l'intérieur de l'objet. Sinon, ils survivront à leur créateur et vous devrez recourir à ipcs et ipcrm (ou un administrateur système) pour vous débarrasser d'eux. C'est pourquoi nous somme passés par les enrobages élaborés dans le programme principal pour convertir les signaux en exceptions : pour que tous les destructeurs soient lancés, que tous les objets d'IPC SysV soient désalloués et que les administrateurs système ne s'occupent pas de notre cas.

sub DESTROY {
    my $obj = shift;
    return unless $obj->{PROPRIETAIRE} == $$;   # évite les désallocations
                                                # redondantes
    shmctl($obj->{SHMKEY}, IPC_RMID, 0) or warn "shmctl RMID : $!";
    $obj->{SEMA}->remove()
        or warn "sema->remove : $!";
}

Les mécanismes d'IPC dont nous avons discuté auparavant souffrent tous d'une importante restriction : ils sont conçus pour une communication entre des processus tournant sur le même ordinateur. (Même si les fichiers peuvent parfois être partagés entre les machines à travers des mécanismes comme NFS, le verrouillage échoue lamentablement sur la plupart des implémentations de NFS, ce qui annihile une grande part des plaisirs des accès concurrents.) Pour des communications génériques sur le réseau, les sockets sont la solution de choix. Bien que les sockets aient été inventées sur BSD, elles se sont rapidement répandues aux autres formes d'Unix et de nos jours, vous pouvez trouver une interface pour les sockets sur à peu près tous les systèmes d'exploitation viables ici-bas. Si vous n'avez pas de sockets sur votre machine, vous allez rencontrer d'énormes difficultés pour utiliser l'Internet.

Avec les sockets, vous pouvez communiquer à la fois avec des circuits virtuels (les flux ou streams TCP) et avec des datagrammes (les paquets UDP). Votre système vous permet peut-être d'en faire plus encore. Mais le type de programmation socket le plus courant utilise TCP sur des sockets du domaine Internet, c'est donc celui que nous détaillerons ici. De telles sockets fournissent des connexions fiables fonctionnant un peu comme deux pipes bidirectionnels qui ne seraient pas limités à une seule machine. Les deux applications reines (killer apps) de l'Internet, l'email et le surf sur le Web, reposent presque exclusivement sur des sockets TCP.

Vous utilisez aussi largement UDP sans le savoir. Chaque fois que votre machine essaie de trouver un site sur l'Internet, elle envoie des paquets UDP à votre serveur DNS pour lui demander la véritable adresse IP. Vous pourriez utiliser UDP vous-même lorsque vous voulez envoyer et recevoir des datagrammes. Les datagrammes sont plus économiques que les connexions TCP précisément parce qu'ils ne sont pas orientés connexion ; c'est-à-dire qu'ils ressemblent moins à un appel téléphonique qu'à un dépôt de lettre dans une boîte. Mais il manque également à UDP la fiabilité offerte par TCP, ce qui le rend plus approprié pour les situations où vous ne vous souciez pas si un ou deux paquets se retrouvent happés, broyés et engloutis. Ou lorsque vous savez qu'un protocole de plus haut niveau fera respecter un certain degré de redondance ou d'échec en douceur (ce que fait DNS).

D'autres choix sont disponibles, mais bien moins courants. Vous pouvez utiliser des sockets du domaine Unix, mais elles ne fonctionnent que pour les communications locales. Divers systèmes implémentent divers autres protocoles qui ne sont pas basés sur IP. Ceux-ci intéressent sans doute quelqu'un quelque part pour faire quelque chose, mais nous devons nous restreindre quelquefois.

Les fonctions Perl s'occupant des sockets ont les mêmes noms que les appels système correspondants en C, mais leurs arguments ont tendance à différer pour deux raisons : premièrement, les handles de fichiers de Perl fonctionnent différemment des descripteurs C ; deuxièmement, Perl connaît déjà la longueur de ses chaînes et il est donc inutile de passer cette information. Voir les détails sur chaque appel système relatif aux sockets au chapitre 29.

Avec du code Perl ancien, on devait utiliser des valeurs codées en dur pour passer des constantes aux fonctions des sockets, ce qui annihilait la portabilité. Comme la plupart des appels système, ceux relatifs aux sockets renvoient discrètement, mais poliment undef lorsqu'ils échouent, au lieu de lever une exception. Il est donc essentiel de vérifier les valeurs renvoyées par ces fonctions, puisque si vous les jetez à la poubelle, elles n'iront pas crier cet échec sur les toits. Si jamais vous voyez du code faisant quelque chose comme positionner explicitement $AF_INET = 2, vous savez que vous êtes dans les problèmes jusqu'au cou. Une approche d'une supériorité incommensurable consiste à utiliser le module Socket ou le module encore plus sympathique IO::Socket, tous deux standard. Ces modules fournissent diverses constantes et des fonctions d'aide dont vous aurez besoin pour mettre en place des clients et des serveurs. Pour une réussite optimale, vos programmes de sockets devraient toujours commencer ainsi (n'oubliez pas non plus d'ajouter l'option de vérification de marquage -T sur la ligne shebang (commençant par #!) pour les serveurs) :

#!/usr/bin/perl -w
use strict;
use sigtrap;
use Socket; # ou IO::Socket

Comme nous l'avons fait remarquer ailleurs, Perl est à la merci de vos bibliothèques C pour la plupart de ses fonctionnalités concernant le système, et tous les systèmes n'implémentent pas toutes les sortes de sockets. Il est probablement plus sûr de s'en tenir avec les opérations sur les sockets normales TCP et UDP. Par exemple, si vous voulez que votre code ait une chance d'être portable vers des systèmes auxquels vous n'avez pas pensé, ne vous attendez pas à ce qu'ils implémentent un protocole fiable avec des paquets séquencés. Ne vous attendez pas non plus à passer des descripteurs de fichiers ouverts entre des processus n'ayant aucun rapport les uns avec les autres sur des sockets du domaine Unix. (Si, si, vous pouvez vraiment faire cela sur de nombreuses machines Unix — voir recvmsg(2) dans votre page de manuel locale.)

Si vous voulez juste utiliser un service standard de l'Internet comme le mail, les forums de discussion, le service de noms de domaine, FTP, Telnet, le Web et ainsi de suite, alors plutôt que de repartir de zéro, essayez d'utiliser les modules existants de CPAN. Les modules tout faits, conçus pour cela, comprennent : Net::SMTP (ou Mail::Mailer), Net:NNTP, Net::DNS, Net::FTP, Net::Telnet et les divers modules relatifs à HTTP. Les familles de modules libnet et libww comprennent toutes deux de nombreux modules individuels pour la communication en réseau. Les zones de modules sur CPAN qui peuvent vous intéresser sont dans la section 5 sur la Communication en réseau et dans la section 15, sur les Utilitaires de serveurs et de démons.

Dans les paragraphes qui suivent, nous présentons plusieurs exemples de clients et de serveurs sans grande quantité d'informations sur chaque fonction utilisée, car ce serait en grande partie une recopie pure et simple de ce que nous avons déjà écrit au chapitre 29, Fonctions.

16-5-a. Clients en réseau▲

use IO::Socket::INET;

$socket = IO::Socket::INET->new(PeerAddr => $hote_distant,
                                PeerPort => $port_distant,
                                Proto => "tcp",
                                Type => SOCK_STREAM)
    or die "N'a pas pu se connecter à $hote_distant:$port_distant : $!\n";
# envoie quelque chose sur la socket,
print $socket "Pourquoi ne m'appelles-tu plus jamais ?\n";

# lit la réponse distante,
$reponse = <$socket>;

# et termine la connexion lorsque nous avons fini
close($socket);

$socket = IO::Socket::INET->new("www.google.org:80")
    or die "N'a pas pu se connecter au port 80 de google: $!";

use Socket;

# crée une socket
socket(Serveur, PF_INET, SOCK_STREAM, getprotobyname('tcp'));

# construit l'adresse de la machine distante
$adr_internet = inet_aton($hote_distant)
    or die "N'a pas pu convertir $hote_distant en adresse Internet : $!\n";
$adr_p = sockaddr_in($port_distant, $adr_internet);

# se connecte
connect(Serveur, $adr_p)
    or die "N'a pas pu se connecter à $hote_distant:$port_distant : $!\n";

select((select(Serveur), $| = 1)[0]); # active la mise en tampon
                                      # des commandes
# envoie quelque chose sur la socket
print Serveur "Pourquoi ne m'appelles-tu plus jamais ?\n";

# lit la réponse distante
$reponse = <Serveur>;

# et termine la connexion lorsque nous avons fini
close(Serveur);

# plus d'écriture vers le serveur
shutdown(Serveur, 1);     # constante Socket::SHUT_WR dans la v5.6

16-5-b. Serveurs en réseau▲

use IO::Socket::INET;
$serveur = IO::Socket::INET->new(LocalPort => $port_serveur,
                                 Type => SOCK_STREAM,
                                 Reuse => 1,
                                 Listen => 10 ) # ou SOMAXCONN
    or die "N'a pas pu être un serveur TCP sur le port $port_serveur : $!\n";

while ($client = $serveur->accept()) {
    # $client est la nouvelle connexion
}

close($serveur);

use Socket;

# crée la socket
socket(Serveur, PF_INET, SOCK_STREAM, getprotobyname('tcp'));

# pour pouvoir redémarrer rapidement notre serveur
setsockopt(Serveur, SOL_SOCKET, SO_REUSEADDR, 1);

# construit l'adresse de la socket
$mon_adr = sockaddr_in($port_serveur, INADDR_ANY);
bind(Serveur, $mon_adr)
    or die "N'a pas pu s'attacher au port $port_serveur : $!\n";

# établit une file pour connexions entrantes
listen(Serveur, SOMAXCONN)
    or die "N'a pas pu écouter sur le port $port_serveur : $!\n";

# accepte et traite les connexions
while (accept(Client, Serveur)) {
    # Fait quelque chose avec la nouvelle connexion Client
}

close(Server);

use Socket;
$autre_extremite = getpeername(Client)
    or die "N'a pas pu identifier l'autre extrémité : $!\n";
($port, $adr_i) = unpack_sockaddr_in($autre_extremite);
$ip_reelle = inet_ntoa($adr_i);
$nom_hote_pretendu = gethostbyaddr($adr_i, AF_INET);

@recherche_noms = gethostbyname($nom_hote_pretendu)
    or die "N'a pas pu faire la conversion inverse de $nom_hote_pretendu : $!\n";
@ips_resolues = map{inet_ntoa($_)} $recherche_noms[ 4 .. $#recherche_noms ];
$usurpation_potentielle = !grep { $ip_reelle eq $_ } @ips_resolues;

REQUETE: 
while (accept(Client, Serveur)) {
    if ($pid_fils = fork) {
        close Client;  # le père ferme le handle inutilisé
        next REQUETE;
    }
    defined($pid_fils) or die "fork impossible : $!" ;

    close Serveur;     # le fils ferme le handle inutilisé

    select(Client);    # nouveau handle par défaut pour les affichages
    $| = 1;            # vidage de tampon automatique

    # le code par connexion des fils fait ses entrées/sorties avec
    # le  handle Client
    $entree = <Client>;
    print Client "affichage\n"; # ou STDOUT, c'est la même chose

    open(STDIN, "<<&Client")
            or die "impossible de dupliquer le client : $!";
    open(STDOUT, ">&Client")
            or die "impossible de dupliquer le client : $!";
    open(STDERR, ">&Client")
            or die "impossible de dupliquer le client : $!";

    # lance la calculatrice, ce n'est qu'un exemple
    system("bc -l");              # ou ce que vous préférez, pourvu
                                  # qu'il n'y ait pas de séquences
                                  # d'échappement du shell !
    print "fini\n"; # toujours au client
    close Client;
    exit; # empêche le fils de retourner à accept
}

16-5-c. Passage de message▲

#!/usr/bin/perl
# retardhorloge - compare les horloges d'autres systèmes avec celle-ci
#                 sans arguments, broadcast à quiconque est à l'écoute.
#                 attend une réponse pendant une demi-seconde.

use v5.6.0;  # or une version supérieure
use warnings;
use strict;
use Socket;

unshift(@ARGV, inet_ntoa(INADDR_BROADCAST))
    unless @ARGV;

socket(my $sock_mess, PF_INET, SOCK_DGRAM, getprotobyname("udp"))
    or die "socket : $!";

# certaines machines ont besoin de ceci. Ça ne devrait pas faire de
# mal aux autres.
setsockopt($sock_mess, SOL_SOCKET, SO_BROADCAST, 1)
    or die "setsockopt : $!";

my $no_port = getservbyname("time", "udp")
    or die "pas de port udp time";

for my $cible (@ARGV) {
    print "Envoi à $cible:$no_port\n";
    my $adr_dest_p = sockaddr_in($no_port, inet_aton($cible));
    send($sock_mess, "x", 0, $adr_dest_p)
        or die "send : $!";
}

# le service d'horloge renvoie une heure sur 32 bits en secondes
# depuis 1900
my $DEPUIS_1900_A_ORIGINE = 2_208_988_800;
my $fmt_heure = "N"; # et ceci en format binaire
my $lg_heure = length(pack($fmt_heure, 1)); # n'importe quel nombre
                                            # convient

my $masque_entree = ''; # chaîne pour stocker les bits de fileno bits
                        # pour le select
vec($masque_entree, fileno($sock_mess), 1) = 1;

# n'attend une entrée qu'une demi-seconde
while (select(my $masque_sortie = $masque_entree, undef, undef, 0.5)) {
    defined(my $adr_src_p = recv($sock_mess, my $heure_bin, $lg_heure, 0))
        or die "recv : $!";
    my($port, $adr_ip) = sockaddr_in($adr_src_p);
    my $hote_emet = sprintf "%s [%s]",
                      gethostbyaddr($adr_ip, AF_INET) || 'UNKNOWN',
                      inet_ntoa($adr_ip);
    my $delta = unpack($fmt_heure, $heure_bin) -
                      $DEPUIS_1900_A_ORIGINE -time();
    print "L'horloge sur $hote_emet est en avance de $delta
           secondes sur celle-ci.\n"; 
}

Nous ne nous étendrons pas trop sur le modèle de processus ici, simplement parce qu'il est dominant tout au long du reste de ce livre. Perl est issu des systèmes Unix, il a donc adopté la notion que chaque processus accomplit son propre travail. Si un processus veut démarrer un traitement parallèle, il doit logiquement démarrer un processus parallèle ; c'est-à-dire qu'il doit faire un fork pour avoir un nouveau processus poids lourd, qui ne partage par défaut que très peu de choses avec son processus père, si ce n'est certains descripteurs de fichiers. (Le père et le fils peuvent sembler partager beaucoup plus, mais une grande partie de l'état du processus père est dupliquée dans le processus fils que réellement partagée au sens logique du terme. Le système d'exploitation peut bien entendu faire preuve de paresse quand il s'agit de forcer cette séparation logique, auquel cas nous appelons cela une sémantique de copie lors d'écritures (copy-on-write), mais nous ne ferions pas de copie du tout, s'il n'y avait pas en premier lieu de séparation logique.)

Historiquement, cette vision industrielle du traitement multiprocessus a posé de petits problèmes sur les systèmes Microsoft, car Windows n'avait pas de modèle multiprocessus bien développé (et il ne se reposait pas souvent sur ce qu'il avait à cet égard pour la programmation parallèle). Il a typiquement adopté à la place une approche multithread.

Toutefois, au prix d'efforts héroïques, la version 5.6 de Perl implémente maintenant l'opération fork sur Windows en clonant un nouvel objet interpréteur à l'intérieur du même processus. Cela signifie que la plupart des exemples utilisant fork dans le reste de ce livre fonctionneront maintenant sur Windows. L'interpréteur cloné partage du code immuable avec les autres interpréteurs, mais reçoit sa propre copie des données avec lesquelles il s'amusera. (Bien entendu, il peut toujours y avoir des problèmes avec les bibliothèques C qui ne comprennent pas les threads.)

Cette approche du traitement multiprocessus a été baptisée ithreads, comme raccourci pour « threads d'interpréteurs ». L'émulation de fork pour les systèmes Microsoft a déclenché l'implémentation des ithreads. Toutefois, nous avons rapidement réalisé que, bien les autres interpréteurs tournaient sous des threads distincts, ils tournaient dans le même processus, il serait donc facile de faire partager des données à ces interpréteurs séparés, même s'ils ne les partageaient pas par défaut.

C'est exactement l'inverse du modèle multithread typique, dans lequel tout est partagé par défaut et où vous devez vous échiner à ne pas partager quelque chose. Mais vous ne devriez pas voir ces deux modèles comme étant complètement distincts l'un de l'autre, car ils essaient tous deux de construire un pont au-dessus de la même rivière ; ils ne font que le construire sur des berges opposées. La véritable solution à tout problème de traitement parallèle est de mêler un certain degré de partage dans un certain degré d'égoïsme.

Ainsi, le but à long terme est d'étendre le modèle d'ithreads pour permettre autant de partage que vous avez besoin ou que vous voulez. Toutefois, à l'heure où nous écrivons ces lignes, la seule interface pour les ithreads visible par l'utilisateur est l'appel fork sous les portages Microsoft de Perl. Nous pensons que cette approche produira éventuellement des programmes plus propres que l'approche multithread standard. À la base, il est plus facile de gérer une économie où vous présumez que chacun possède ce qu'il a, plutôt que de présumer que tout le monde possède tout. Ce n'est pas que l'on attend des gens qu'ils ne partagent pas dans une économie capitaliste, ou qu'ils ne détournent pas de fonds publics(140) dans une économie communiste. Ces choses tendent à s'équilibrer. Il arrive que l'on soit dans une économie socialiste. Mais avec d'importants groupes de personnes, le partage de tout par défaut ne fonctionne que si vous avez un « chef en chef » avec un grand couteau de boucher, pensant que tout lui appartient.

Bien entendu, le véritable gouvernement de tout ordinateur est géré par un dictateur fasciste connu sous le nom de système d'exploitation. Mais un dictateur avisé sait lorsqu'il faut faire croire aux gens qu'ils sont capitalistes — et lorsqu'il faut leur faire croire qu'ils sont communistes.

Le modèle de thread pour le traitement parallèle a tout d'abord été introduit dans Perl comme une fonctionnalité expérimentale dans la version 5.005. (Nous voulons dire par « modèle de thread », des threads partageant des ressources de données par défaut, non les nouveaux ithreads de la version 5.6.) Par certains côtés, ce modèle de thread est toujours une fonctionnalité expérimentale même en 5.6, car Perl est un langage riche et le traitement multithread peut mettre un fouillis même dans le plus simple des langages. Il existe toujours des coins et recoins de la sémantique de Perl qui n'interagissent pas très bien avec la notion que tout soit partagé. Le nouveau modèle des ithreads est une tentative pour contourner ces problèmes et, à un moment à l'avenir, il se peut que le modèle de thread actuel soit englobé dans le modèle d'ithread (lorsque nous aurons une interface aux ithreads qui dira « partagez tout ce que vous pouvez par défaut »). Mais malgré ses problèmes, l'actuel modèle de thread « expérimental » continue d'être très utile dans plusieurs situations du mode réel où il est préférable d'être un cobaye plutôt que de ne pas avoir de threads. Des applications raisonnablement robustes peuvent être écrites en Perl avec des threads, mais vous devez faire très attention. Vous devriez au moins envisager d'utiliser plutôt fork, si vous pouvez trouver un moyen de résoudre votre problème avec des pipes à la place de structures de données partagées.

Mais certains algorithmes sont plus simples à exprimer si de multiples tâches peuvent accéder facilement et efficacement au même jeu de données.(141) Cela produit du code plus petit et plus simple. Et puisque le noyau n'a pas à copier des tableaux de pages pour les données (même s'il fait de la copie lors d'écriture (copy-on-write)) lors de la création de thread, il devrait être plus rapide de démarrer une tâche de cette manière. De même, le changement de contexte peut être plus rapide si le noyau n'a pas besoin d'échanger (swap) des tableaux de pages. (En fait, pour les threads au niveau de l'utilisateur, le noyau n'est pas impliqué du tout — bien que les threads au niveau de l'utilisateur aient bien entendu des problèmes que les threads du noyau n'ont pas.)

Voici pour les bonnes nouvelles. Maintenant, passons à d'autres plus sujettes à réclamations. Nous avons déjà mentionné que le traitement des threads était quelque peu expérimental en Perl, mais, même s'il ne l'était pas, la programmation avec des threads est assez traître. La capacité d'un flux d'exécution à placer, qu'on le veuille ou non, des trous dans l'espace des données d'un autre, est susceptible de provoquer des désastres, plus que vous ne pouvez l'imaginer. Vous pourriez vous dire : « C'est facile à corriger, je n'ai qu'à mettre des verrous sur les données partagées. » D'accord, le verrouillage des données partagées est indispensable, mais disposer de protocoles de verrouillage qui soient corrects est une difficulté de notoriété publique, avec des erreurs générant des verrous mortels (deadlocks) ou des résultats non déterministes. Si vous avez des problèmes de synchronisation dans votre programme, l'emploi de threads va non seulement les aggraver, mais les rendra également plus difficiles à localiser.

Vous êtes non seulement responsable de l'honnêteté de vos propres données partagées, mais également de celle des modules Perl et des bibliothèques C que vous appelez. Votre code Perl a beau être sécurisé au niveau des threads à 100 %, si vous appelez un module ou un sous-programme C qui ne soit pas sûr au niveau des threads, vous êtes grillé. Vous devriez présumer qu'aucun module n'est sûr au niveau des threads à moins de le prouver. Ceci inclut même certains des modules standard. Peut-être même la plupart d'entre eux.

Nous ne vous avons pas déjà découragé ? Non ? Alors nous mettrons l'accent sur le fait que vous êtes quelque peu à la merci des bibliothèques de votre système d'exploitation pour le traitement des threads lorsqu'il s'agit de politiques d'ordonnancement et de préemption. Certaines bibliothèques de threads ne font du basculement de thread que sur les appels système bloquants. Certaines bloquent le processus entier si un seul thread fait un appel système bloquant. Certaines ne basculent les threads que sur l'expiration d'un délai quantifiable (soit d'un thread, soit d'un processus). Certaines ne basculent les threads qu'explicitement.

Oh, et pendant qu'on y est, si votre processus reçoit un signal, déterminer à quel thread ce signal est délivré est complètement dépendant du système.

Pour faire de la programmation de thread en Perl, vous devez compiler une version spéciale de Perl en suivant les instructions fournies dans le fichier README.threads dans le répertoire des sources de Perl. Il est à peu près garanti que ce Perl spécial tournera moins vite que votre exécutable Perl standard.

Ne présupposez pas que, puisque vous savez comment les threads sont programmés dans d'autres modèles (POSIX, DEC, Microsoft, etc.), vous savez comment les threads fonctionnent en Perl. Comme avec d'autres choses en Perl, Perl est du Perl, non du C++ ou du Java ou quoi que ce soit d'autre. Par exemple, il n'y a pas de priorités de thread en temps réel (et aucun moyen de contourner leur absence). Il n'y a pas non plus de verrous d'exclusion mutuelle (mutex). Utilisez simplement le verrouillage ordinaire ou peut-être le module Thread::Semaphore ou les mécanismes de cond_wait.

Toujours pas découragé ? Bien ! Car les threads sont vraiment sympas. Vous pouvez prévoir de vous amuser.

17-2-a. Le module Thread▲

use Thread;
...
$t = Thread->new(\&fonc, $arg1, $arg2);

my $quelque_chose;
$t = Thread->new( sub { dit($quelque_chose) } );

use Thread qw(async);
...
my $quelque_chose;
$t = async {
    dit($quelque_chose);
};

$val_ret = $t->join();  # moissonne le thread $t

use Thread 'async';

$t1 = async {
    my @trucs = getpwuid($>);
    return @trucs;
};

$t2 = async {
    my $mess = `cat /etc/motd`;
    return $mess;
};

@liste_ret = $t1->join();
$val_ret = $t2->join();

print "Le 1er fils a renvoyé @liste_ret\n";
print "Le 2ème fils a renvoyé $val_ret\n";

$val_ret = $t->eval();           # capture les erreurs lorsque les
                                 # threads se rejoignent
if ($@) {
    warn "échec du thread : $@";
}
else {
    print "le thread a renvoyé $ret_val\n";
}

$son_num_tid = $t1->tid();

$mon_tid = Thread->self->tid(); # $$ pour les threads, pour ainsi dire

Thread::equal($t1, $t2)
$t1->equal($t2)
$t1->tid() == $t2->tid()

for my $t (Thread->list()) {
    printf "$t a un tid = %d\n", $t->tid();
}

use Thread 'yield';
yield();

use strict;
use Thread 'yield';
yeild;           # Le compilateur se désole, puis arrête tout
yield;           # Ok.

17-2-b. Accès aux données▲

lock $var;
lock @valeurs;
lock %hachage;

lock @valeurs;         # dans le thread 1
...
lock $valeurs[23];     # dans le thread 2 --- ne verrouille pas !

use Thread qw/async yield/;
my $var = 0;
sub une_inflation {
    if ($var == 0) {
        yield;
        $var++;
    }
}

my $t1 = new Thread \&une_inflation;
my $t2 = new Thread \&une_inflation;

for my $t ($t1, $t2) { $t->join }
print "var vaut $var\n";

sub une_inflation {
    lock $var;
    if ($var == 0) {
        yield;
        $var++;
    }
}

sub une_inflation {
    {
        lock $var;
        if ($var == 0) {
            yield;
            $var++;
        }
    } # le verrou est relâché ici !
    # autre code avec $var déverrouillée
}

my $t1 = async {
    lock $a; yield; lock $b;
    $a++; $b++
};
my $t2 = async {
    lock $b; yield; lock $a;
    $b++; $a++
};

lock &fonc;

use Thread qw/async yield/;
my $fini = 0;
sub bricole {
    my $arg = shift;
    my $tid = Thread->self->tid;
    print "thread $tid : bricole $arg\n";
    yield;
    unless ($fini) {
        yield;
        $fini++;
        bricole($arg + 10);
    }
}

my @t;
for my $i (1..3) {
    push @t, Thread->new(\&bricole, $i);
}
for (@t) { $_->join }
print "fini vaut $fini\n";

thread 1 : bricole 1
thread 2 : bricole 2
thread 3 : bricole 3
thread 1 : bricole 11
thread 2 : bricole 12
thread 3 : bricole 13
fini vaut 3

for my $i (1..3) {
    push @t, async {
        lock &bricole;
        bricole($i);
    };
}
for (@t) { $_->join }
print "fini vaut $fini\n";

thread 1 : bricole 1
thread 1 : bricole 11
thread 2 : bricole 2
thread 3 : bricole 3
fini vaut 1

sub bricole : locked {
    # comme avant
}

sub bricole ($) : locked {
    # comme avant
}

sub bricole : locked method {
    # comme avant
}

use Thread qw(async cond_wait cond_signal);
my $var_wait = 0;
async {
    lock $var_wait;
    $var_wait = 1;
    cond_wait $var_wait until $var_wait == 2;
    cond_signal($var_wait);
    $var_wait = 1;
    cond_wait $var_wait until $var_wait == 2;
    $var_wait = 1;
    cond_signal($wait_var);
};

async {
    lock $var_wait;
    cond_wait $var_wait until $var_wait == 1;
    $var_wait = 2;
    cond_signal($var_wait);
    cond_wait $var_wait until $var_wait == 1;
    $var_wait = 2;
    cond_signal($wait_var);
    cond_wait $var_wait until $var_wait == 1;
};

17-2-c. Autres modules de thread▲

use Thread qw/async/;
use Thread::Queue;

my $Q = Thread::Queue->new();
async {
    while (defined($donnee = $Q->dequeue)) {
        print "$donnee retiré de la file\n";
    }
};

$Q->enqueue(12);
$Q->enqueue("A", "B", "C");
$Q->enqueue($thr);
sleep 3;
$Q->enqueue(\%ENV);
$Q->enqueue(undef);

12 retiré de la file A retiré de la file
B retiré de la file
C retiré de la file
Thread=SCALAR(0x8117200) retiré de la file
HASH(0x80dfd8c) retiré de la file

use Thread::Semaphore;
$mutex = Thread::Semaphore->new($MAX);

$mutex->down();

$mutex->up();

Vous pouvez décomposer le cycle de vie d'un programme Perl en quatre phases distinctes, chacune avec ses propres étapes indépendantes. La première et la dernière sont les plus intéressantes et les deux du milieu sont optionnelles. Ces phases sont décrites à la figure 18-1.

1. La phase de compilation

• Durant la phase 1, la phase de compilation, le compilateur convertit votre programme vers une structure de données appelée un arbre syntaxique. En plus des techniques traditionnelles d'analyse syntaxique, Perl en emploie une bien plus puissante : il utilise les blocs BEGIN pour guider toute compilation plus approfondie. Les blocs BEGIN sont passés à l'interpréteur pour être lancés dès qu'ils ont été analysés, ce qui les lance effectivement dans l'ordre du premier arrivé (FIFO : first in, first out). Ceci comprend toutes les déclarations use et no ; celles-ci ne sont que des blocs BEGIN déguisés. Tous les blocs CHECK, INIT et END sont programmés par le compilateur pour une exécution différée.
• Les déclarations lexicales sont notées, mais leurs affectations ne sont pas exécutées. Toutes les constructions eval BLOC, s///e et les expressions régulières non interpolées sont compilées ici et les expressions constantes sont préévaluées. Le compilateur a maintenant fini, à moins qu'il ne soit rappelé au travail plus tard. À la fin de cette phase, l'interpréteur est à nouveau appelé pour exécuter tous les blocs CHECK programmés dans l'ordre du dernier arrivé (LIFO : last in, first out). La présence ou l'absence d'un bloc CHECK détermine si nous allons ensuite à la phase 2 ou si nous sautons directement à la phase 4.

2. La phase de génération de code (optionnelle)

• Les blocs CHECK sont installés par les générateurs de code ; cette phase optionnelle n'intervient donc que si vous avez utilisé explicitement l'un de ces générateurs de code (décrit plus tard dans Générateurs de codes). Ceux-ci convertissent le programme compilé (mais non encore lancé) soit en code source en C, soit en bytecode Perl sérialisé — une séquence de valeurs exprimant des instructions Perl internes. Si vous choisissez de générer du code source en C, il peut éventuellement produire un fichier appelé une image exécutable en langage machine natif.(145)
• Arrivé à ce point, votre programme se met en hibernation. Si vous avez fait une image exécutable, vous pouvez directement aller à la phase 4 ; sinon, vous devez reconstruire les bytecodes lyophilisés en phase 3.

3. La phase de reconstruction de l'arbre syntaxique (optionnelle)

• Pour réanimer le programme, son arbre syntaxique doit être reconstruit. Cette phase n'existe que si la génération de code a eu lieu et si vous avez choisi de générer du bytecode. Perl doit tout d'abord reconstituer ses arbres syntaxiques à partir de cette séquence de bytecode avant que le programme puisse être lancé. Perl ne se lance pas directement à partir des bytecodes ; ce serait trop lent.

4. La phase d'exécution

• Finalement, ce que vous attendiez tous : faire tourner votre programme.(146) L'interpréteur prend l'arbre syntaxique (qu'il obtient directement depuis le compilateur ou indirectement depuis la génération de code et la reconstruction consécutive de l'arbre) et l'exécute. (Ou, si vous avez généré un fichier image exécutable, il peut être lancé en tant que programme indépendant puisqu'il contient un interpréteur Perl intégré.)
• Au début de cette phase, avant que ce ne soit à votre programme principal de se lancer, tous les blocs INIT programmés sont exécutés dans l'ordre du premier arrivé (FIFO). Puis, votre programme principal est lancé. L'interpréteur peut faire à nouveau appel au compilateur comme cela est nécessaire lorsqu'il rencontre un eval CHAÎNE, un do FICHIER ou une instruction require, une construction s///ee ou une reconnaissance de motif avec une variable interpolée contenant une assertion de code valide.
• Lorsque votre programme principal a fini, tous les blocs END différés sont finalement exécutés, cette fois-ci dans l'ordre du dernier arrivé (LIFO). Le bloc vu en tout premier sera exécuté en dernier et ensuite vous aurez fini. (Les blocs END ne sont court-circuités que si vous appelez un exec ou si votre processus est balayé par une erreur catastrophique non interceptée. Les exceptions ordinaires ne sont pas considérées comme étant catastrophiques.)

Maintenant nous allons discuter de ces phases plus en détail et dans un ordre différent.

Perl est toujours dans l'un des deux modes d'opération : soit il est en train de compiler votre programme, soit il est en train de l'exécuter — jamais les deux en même temps.

Tout au long de ce livre, nous nous référons à certains événements comme se déroulant à la compilation (compile time) ou alors nous disons que « le compilateur Perl fait ceci ou cela ». À d'autres endroits, nous mentionnons qu'autre chose se déroule à l'exécution (run time) ou que « l'interpréteur Perl fait ceci ou cela ». Bien que vous pouvez continuer à vivre en pensant que « Perl » désigne à la fois le compilateur et l'interpréteur, comprendre lequel de ces deux rôles est en train de jouer Perl à un moment donné est essentiel pour comprendre pourquoi certaines choses se déroulent comme elles le font et non autrement. L'exécutable perl implémente les deux rôles : tout d'abord le compilateur, puis l'interpréteur. (D'autres rôles sont également possibles ; perl est aussi un optimisateur et un générateur de code. Parfois, c'est même un tricheur — mais tout cela dans la joie et la bonne humeur.)

Il est également important de comprendre la distinction entre la phase de compilation et la compilation (compilation time) ainsi qu'entre la phase d'exécution et l'exécution (run time). Une « phase » est un concept à grande échelle. Alors que la compilation et l'exécution sont des concepts à petite échelle. Une phase de compilation donnée fait surtout des travaux de compilation, mais elle fait également quelques travaux d'exécution via les blocs BEGIN. Une phase d'exécution donnée fait surtout des travaux d'exécution, mais elle fait également quelques travaux de compilation par l'intermédiaire d'opérateurs comme eval CHAÎNE.

Dans le déroulement typique des événements, le compilateur Perl lit le source de votre programme en entier avant que l'exécution ne commence. C'est ici que Perl analyse les déclarations, les instructions et les expressions pour s'assurer qu'elles sont syntaxiquement valides.(147) S'il trouve une erreur de syntaxe, le compilateur tente de la corriger pour qu'il puisse rendre compte des erreurs suivantes dans le code source. Parfois, ceci fonctionne et parfois non ; les erreurs de syntaxe ont une tendance fâcheuse à déclencher une cascade de fausses alertes. Perl abandonne, avec un sentiment de frustration, après environ 10 erreurs.

En plus de l'interpréteur qui traite les blocs BEGIN, le compilateur traite votre programme avec la connivence de trois agents notionnels. Ceux-ci sont parfois appelés « lexèmes », mais vous les rencontrerez plus souvent sous le nom de tokens dans les textes parlant des langages de programmation. L'analyseur lexical est parfois appelé un tokener ou un scanner et ce qu'il fait est parfois appelé de la lexicalisation (lexing) ou de la tokenisation (tokening). L'analyseur syntaxique (parser) essaie alors de dégager un sens des groupes de tokens en les assemblant dans des constructions plus larges, comme des expressions et des instructions, basées sur la grammaire du langage Perl. L'optimisateur réarrange et réduit ces regroupements plus larges en séquences plus efficaces. Il choisit ses optimisations précautionneusement, sans perdre de temps sur des optimisations marginales, car le compilateur Perl doit être rapide comme l'éclair puisqu'il est utilisé en mode load-and-go (c'est-à-dire que l'exécution d'un programme est toujours précédée de sa compilation).

Ceci ne se produit pas dans des étapes indépendantes, mais d'un seul coup avec énormément de dialogues croisés entre les agents. L'analyseur lexical a parfois besoin d'indications de la part de l'analyseur syntaxique pour lever les ambiguïtés sur les différents types possibles des tokens qu'il regarde. (Curieusement, la portée lexicale est l'une des choses que l'analyseur lexical ne comprend pas, car c'est l'autre sens de « lexique ».) L'optimisateur a également besoin de garder une trace de ce que l'analyseur syntaxique est en train de faire, car certaines optimisations ne peuvent être faites avant que l'analyseur syntaxique n'ait atteint un certain point, tel que la fin d'une expression, d'une instruction, d'un bloc ou d'un sous-programme.

Vous pouvez trouver étrange que le compilateur Perl fasse toutes ces choses en une fois plutôt que les unes après les autres, mais il s'agit certainement du même processus confus que lorsque vous essayez de comprendre un langage naturel à la volée alors que vous êtes en train de l'écouter ou de le lire. Vous n'attendez pas la fin d'un chapitre pour comprendre ce que la première phrase voulait dire. Vous pourriez penser aux correspondances suivantes :

En supposant que l'analyse syntaxique se passe bien, le compilateur estime que ce que vous lui avez passé en entrée est une histoire valide — heu, pardon, un programme valide. Si vous utilisez l'option -c lorsque vous lancez votre programme, il affiche un message « syntax OK » et se termine. Sinon, le compilateur passe les fruits de ses efforts aux autres agents. Ces « fruits » se présentent sous forme d'un arbre syntaxique. Chaque fruit de l'arbre — ou chaque nœud, comme on les appelle — représente l'un des codes d'opération (opcodes) internes de Perl et les branches de l'arbre représentent le schéma d'évolution de cet arbre. Éventuellement, les nœuds seront enchaînés de manière linéaire, les uns après les autres, pour indiquer l'ordre dans lequel le système d'exécution devra les passer en revue.

Chaque code d'opération est la plus petite unité d'instruction exécutable que Perl peut appréhender. Vous pourriez rencontrer une expression telle que $a = -($b + $c) comme étant une seule instruction, mais Perl l'appréhende comme six codes d'opération séparés. Présenté sous un format simplifié, l'arbre syntaxique pour cette expression ressemblerait à la figure 18-2. Les numéros représentent l'ordre de parcours que le système d'exécution de Perl suivra éventuellement.

Perl n'est pas un compilateur travaillant en une seule passe comme certains pourraient le penser. (Les compilateurs travaillant en une seule passe sont très doués pour rendre les choses faciles à l'ordinateur et difficiles au programmeur.) Il s'agit réellement d'un compilateur multipasse, faisant des optimisations et consistant en au moins trois passes logiques différentes, qui dans la pratique s'entremêlent. Les passes 1 et 2 sont lancées en alternance alors que le compilateur fait des allers-retours à toute vitesse le long de l'arbre syntaxique durant sa construction ; la passe 3 se produit dès qu'un sous-programme ou qu'un fichier est entièrement analysé. Voici ces différentes passes :

Passe 1 : Analyse ascendante (Bottom-up parsing)

• Durant cette passe, l'arbre syntaxique est construit par l'analyseur syntaxique yacc(1) en utilisant les tokens qu'on lui donne à partir de l'analyseur lexical sous-jacent (qui pourrait être considéré comme une autre phase logique à titre individuel). « Ascendante » signifie seulement que l'analyseur syntaxique connaît les feuilles de l'arbre avant ses branches et sa racine. Il calcule vraiment les choses de bas en haut dans la figure 18-2, puisque nous avons dessiné la racine en haut, dans la pure tradition idiosyncratique des informaticiens. (Et des linguistes.)
• Alors que chaque nœud contenant un code d'opération est construit, une vérification de bon sens par code d'opération est effectuée pour contrôler si la sémantique est valide, comme le bon nombre et le type correct des arguments utilisés pour appeler les fonctions internes. Alors que chaque sous-section de l'arbre prend forme, l'optimisateur estime les transformations qu'il peut appliquer au sous-arbre entier se trouvant maintenant sous son emprise. Par exemple, une fois qu'il sait qu'une liste de valeurs est passée à une fonction prenant un certain nombre d'arguments, il peut se défaire du code d'opération qui enregistre le nombre d'arguments pour les fonctions en acceptant un nombre variable. Une optimisation plus importante, connue sous le nom de précalcul des expressions constantes (constant folding), est décrite plus loin dans ce paragraphe. Cette passe construit également l'ordre de parcours des nœuds utilisé plus tard pour l'exécution, ce qui est une astuce vraiment géniale, car le départ du parcours n'est presque jamais le nœud supérieur. Le compilateur réalise une boucle temporaire des codes d'opération, avec le nœud supérieur pointant sur le premier code d'opération à parcourir. Lorsque le nœud supérieur est incorporé dans quelque chose de plus gros, cette boucle de codes d'opération est brisée, uniquement pour engendrer une boucle plus grosse avec le nouveau nœud supérieur. La boucle est éventuellement brisée pour de bon lorsque le nœud de départ est poussé dans une autre structure comme un descripteur de sous-programme. L'appelant du sous-programme peut toujours retrouver ce premier code d'opération bien qu'il soit dans les profondeurs de l'arbre, comme c'est le cas dans la figure 18-2. L'interpréteur n'a aucun besoin de revenir en bas de l'arbre pour arriver à comprendre par où commencer.

Passe 2 : Optimisateur descendant (Top-down optimizer)

• Une personne lisant un extrait d'un code Perl (ou d'un code français, pour ce qui nous préoccupe ici) ne peut déterminer le contexte sans examiner les éléments lexicaux l'entourant. Vous ne pouvez parfois pas décider ce qui se passe réellement jusqu'à ce que vous ayez plus d'informations. Que cela ne vous afflige pas pour autant, car vous n'êtes pas seul : le compilateur non plus. Dans cette passe, le compilateur redescend le sous-arbre qu'il vient de construire pour appliquer des optimisations locales, dont la plus remarquable est la propagation de contexte. Le compilateur marque les nœuds avec les contextes appropriés (vide, scalaire, liste, référence ou lvalue) imposés par le nœud courant. Les codes d'opération superflus sont annulés, mais non supprimés, car il est maintenant trop tard pour reconstruire l'ordre d'exécution. Nous compterons sur la troisième passe pour les enlever de l'ordre d'exécution provisoire déterminé par la première passe.

Passe 3 : Optimisateur à lucarne (Peephole optimizer)

• Certaines unités de code ont leur propre espace de stockage dans lequel elles conservent leurs variables de portée lexicale. (De tels espaces sont appelés mémoires de travail ou scratchpads dans le jargon de Perl.) Ces unités comprennent les eval CHAÎNE, les sous-programmes et les fichiers entiers. D'une manière importante du point de vue de l'optimisateur, elles ont chacune leur propre point d'entrée, ce qui signifie qu'alors que nous connaissons l'ordre d'exécution à partir d'ici, nous ne pouvons pas connaître ce qui s'est passé auparavant, car la construction a pu être appelée de n'importe où. Ainsi, lorsque l'une de ces unités a fini d'être analysée, Perl lance un optimisateur regardant par une lucarne, sur ce code. Au contraire des deux passes précédentes, qui parcouraient la structure de branche de l'arbre syntaxique, cette passe-ci parcourt le code dans un ordre d'exécution linéaire, puisqu'elle constitue à la base la dernière opportunité de le faire avant que nous isolions la liste de codes d'opération de l'analyseur syntaxique. La plupart des optimisations ont déjà été effectuées dans les deux premières passes, mais certaines ne le pouvaient pas.
• Des optimisations variées de dernière minute se produisent ici, y compris l'assemblage de l'ordre d'exécution final en court-circuitant les codes d'opération nuls et le fait de détecter lorsque diverses juxtapositions de codes d'opération peuvent être réduites à quelque chose de plus simple. L'identification d'une série de concaténations de chaînes est une optimisation importante puisque vous aimeriez vraiment éviter de copier la même chaîne encore et encore à chaque fois que vous ajoutez un petit quelque chose à la fin. Cette passe ne fait pas que de l'optimisation ; il réalise également une grande quantité de travail « réel » : l'interception de mots simples (barewords), la génération d'avertissements sur des constructions douteuses, la recherche de code peu susceptible d'être atteint, la résolution de clefs de pseudohachages et la recherche de sous-programmes appelés avant que leurs prototypes n'aient été compilés.

Passe 4 : Génération de code (Code generation)

• Cette passe est optionnelle; elle n'est pas utilisée dans le déroulement normal des événements. Mais si l'un des trois générateurs de code — B::Bytecode, B::C ou B::CC — est invoqué, on accède une dernière fois à l'arbre syntaxique. Les générateurs de code émettent soit les bytecodes Perl sérialisés utilisés plus tard pour reconstruire l'arbre syntaxique, soit du code littéral C représentant l'état de l'arbre syntaxique à la compilation.
• La génération de code C est disponible en deux variétés différentes. B::C reconstruit simplement l'arbre syntaxique et le lance en utilisant la boucle habituelle runops() que Perl lui-même utilise durant l'exécution. Tandis que B:CC produit un équivalent C linéarisé et optimisé du chemin emprunté par le code d'exécution (qui ressemble à une table de branchements ( jump table) géante) et l'exécute.

Pendant la compilation, Perl optimise votre code de manières très, très, diverses. Il réarrange le code pour le rendre plus efficace à l'exécution. Il supprime le code qui ne pourra jamais être atteint durant l'exécution, comme un bloc if (0) ou les blocs elsif et else avec un bloc if (1). Si vous utilisez des variables lexicalement typées, déclarées avec my NomClasse $var ou our NomClasse $var et que le paquetage NomClasse avait été initialisé avec le pragma use fields, les accès aux champs constants depuis le pseudohachage sous-jacent sont vérifiés pour y détecter des fautes de frappe et convertis en accès à un tableau. Si vous donnez à l'opérateur sort une routine de comparaison suffisamment simple, comme {$a <=> $b} ou {$b cmp $a}, celle-ci est remplacée par un appel à du code C compilé.

L'optimisation la plus impressionnante de Perl est probablement la manière dont il résout les expressions constantes dès que possible. Considérez par exemple l'arbre syntaxique présenté à la figure 18-2. Si les nœuds 1 et 2 avaient tous deux été des littéraux ou des fonctions constantes, les nœuds 1 à 4 auraient été remplacés par le résultat de ce calcul, ce qui aurait donné quelque chose comme la figure 18-3.

On appelle ceci le précalcul d'expressions constantes (constant folding). Ce précalcul ne se limite pas à des cas simples comme la conversion à la compilation de 2**10 en 1024. Il résout également les appels de fonctions — à la fois les fonctions internes et les sous-programmes déclarés par l'utilisateur remplissant les critères de la section Inclure par référence les fonctions constantes au chapitre 6, Sous-programmes. En réminiscence des compilateurs FORTRAN, célèbres pour leur connaissance de leurs propres fonctions intrinsèques, Perl sait également laquelle de ses fonctions internes appeler durant la compilation. C'est pourquoi lorsque vous essayez de prendre le log de 0.0 ou la racine carrée (sqrt) d'une constante négative, vous encourez une erreur de compilation et non d'exécution, et l'interpréteur n'est pas lancé du tout.(148)

Même les expressions arbitrairement complexes sont résolues très tôt, en déclenchant parfois la suppression de blocs entiers comme celui-ci :

if (2 * sin(1)/cos(1) < 3 && une_fonc() { n_importe_quoi() }

Aucun code n'est généré pour ce qui ne pourra jamais être évalué. Comme la première partie est toujours fausse, une_fonc et n_importe_quoi ne seront jamais appelés. (Ne vous attendez donc pas à faire un goto sur des étiquettes à l'intérieur de ce bloc, car il n'existera même pas à l'exécution.) Si une_fonc était une fonction constante susceptible d'être incluse par référence (inlinable), sa valeur aurait juste été insérée comme si c'était une constante littérale. Vous auriez alors encouru un avertissement « Useless use of a constant in void context » (Utilisation inutile d'une constante dans un contexte vide). Ceci pourrait vous surprendre si vous n'aviez pas réalisé que c'était une constante. Toutefois, si n_importe_quoi était la dernière instruction évaluée dans une fonction appelée dans un contexte non vide (tel que l'optimisateur le détermine), vous n'auriez jamais vu l'avertissement.

Vous pouvez voir le résultat final de l'arbre syntaxique construit après toutes les étapes d'optimisation avec perl -Dx. (L'option -D exige une version spéciale de Perl, permettant le débogage) Voir également le paragraphe sur B::Deparse décrit ci-dessous.

En fin de compte, le compilateur Perl travaille dur (mais pas trop dur) pour optimiser le code afin que, lorsqu'arrive le moment de l'exécution, celle-ci soit accélérée. C'est le moment où votre programme est lancé, alors occupons-nous en maintenant.

À première vue, les programmes Sparc ne tournent que sur des machines Sparc, les programmes Intel ne tournent que sur des machines Intel et les programmes Perl ne tournent que sur des machines Perl. Une machine Perl possède des qualités qu'un programme Perl trouverait idéales dans un ordinateur : une mémoire qui s'alloue et se désalloue automatiquement, des types de données fondamentaux qui sont des chaînes, des tableaux et des hachages dynamiques et n'ont pas de limite de taille et des systèmes qui se comportent à peu près toujours de la même façon. Le travail de l'interpréteur Perl est de faire que n'importe quel ordinateur sur lequel il tourne, apparaisse comme l'une de ces machines Perl idéales.

Cette machine fictive présente l'illusion d'un ordinateur spécialement conçu pour ne rien faire tourner d'autre que des programmes Perl. Chaque code d'opération (opcode) produit par le compilateur est une commande fondamentale dans cet ensemble d'instructions émulées. Au lieu d'un compteur de programme matériel, l'interpréteur ne garde que la trace du code d'opération courant à exécuter. Au lieu d'un pointeur de pile matériel, l'interpréteur possède sa propre pile virtuelle. Cette pile est très importante, car la machine virtuelle Perl (que nous refusons d'appeler une PVM(149)) est une machine reposant sur des opérations de pile. Les codes d'opération de Perl sont appelés en interne des codes PP (abréviation de codes « push-pop », « empiler-dépiler »), car ils manipulent la pile virtuelle de l'interpréteur pour trouver tous les opérandes, traiter les valeurs temporaires et stocker tous les résultats.

Si vous avez jamais programmé en Forth ou en PostScript ou utilisé une calculatrice scientifique HP avec une saisie en RPN (« Reverse Polish Notation », notation polonaise inversée), vous savez comment fonctionne une machine basée sur des opérations de pile. Même si ce n'est pas le cas, le concept est simple : pour ajouter 3 et 4, vous faites les choses dans l'ordre 34+ au lieu de l'ordre conventionnel 3+4. Ce qui signifie en termes d'opérations de pile que vous empilez 3, puis 4 et + dépile ensuite les deux arguments, les additionne et remet 7 dans la pile, où il restera jusqu'à ce que vous en fassiez quelque chose.

Comparé au compilateur Perl, l'interpréteur Perl est un programme rigoureux, presque ennuyeux. Tout ce qu'il fait est de parcourir pas à pas les codes d'opération compilés, un à un, et de les acheminer vers l'environnement d'exécution de Perl, c'est-à-dire, vers la machine virtuelle Perl. C'est juste un tas de code C, n'est-ce pas ?

En fait, ce n'est pas du tout ennuyeux. Une machine virtuelle Perl garde la trace d'une grande quantité de contextes dynamiques à votre place pour que vous n'ayez pas à le faire. Perl entretient un bon nombre de piles, que vous n'avez pas à connaître, mais que nous énumérerons ici, seulement pour vous épater :

pile d'opérandes (operand stack)

• Il s'agit de la pile dont nous avons déjà parlé.

pile de sauvegardes (save stack)

• Là où sont sauvegardées les valeurs déclarées locales en attendant d'être restaurées. Plusieurs routines internes déclarent également des valeurs comme étant locales sans que vous le sachiez.

pile de portées (scope stack)

• Le contexte dynamique poids plume, qui contrôle le moment où la pile de sauvegardes doit être dépilée.

pile de contextes (context stack)

• Le contexte dynamique poids lourd ; qui a appelé qui pour en arriver là où vous êtes. La fonction caller parcourt cette pile. Les fonctions de contrôle de boucle examinent cette pile pour trouver quelle boucle contrôler. Lorsque vous épluchez la pile de contexte, la pile de portées est épluchée en conséquence, ce qui restaure toutes vos variables locales à partir de la pile de sauvegardes, même si vous aviez quitté le contexte précédent par le biais de procédés infâmes comme de lever une exception et sortir avec un longjmp(3).

pile de changements d'environnement ( jumpenv stack)

• La pile des contextes de longjmp(3) qui nous permettent de lever des exceptions ou de quitter le programme de manière expéditive.

pile de retours (return stack)

• Là d'où nous sommes partis lorsque nous sommes entrés dans ce sous-programme.

pile de repère (mark stack)

• Là où commence, dans la pile d'opérandes, la liste d'arguments courante pour les fonctions avec un nombre variable d'arguments (variadic).

piles de mémoires de travail lexicales récursives (recursive lexical pad stacks)

• Là où sont stockés les variables lexicales et les autres « registres de mémoires de travail » (scratch register) lorsque les sous-programmes sont appelés récursivement.

Bien entendu, il y a la pile C dans laquelle sont stockées toutes les variables C. Perl essaie en fait d'éviter de se reposer sur la pile du C pour le stockage de valeurs sauvegardées, puisque longjmp(3) court-circuite la restauration appropriée de telles valeurs.

Tout ceci pour dire que la vision habituelle que l'on a d'un interpréteur, un programme qui en interprète un autre, est vraiment inadéquate pour décrire ce qui se passe ici. Oui, il existe du code C implémentant des codes d'opération, mais lorsque nous parlons d'« interpréteur », nous voulons dire quelque chose de plus que cela, de la même manière que lorsque nous parlons de « musicien », nous voulons dire quelque chose de plus qu'un ensemble d'instructions d'ADN changeant les notes en sons. Les musiciens sont des organismes réels, vivants et ont une « condition ». Il en va de même pour les interpréteurs.

En particulier, tout ce contexte dynamique et lexical, ainsi que les tables de symboles globales, plus l'arbre syntaxique, plus un thread d'exécution, est ce que nous appelons un interpréteur. En tant que contexte d'exécution, un interpréteur commence son existence avant même que le compilateur ne démarre et il peut se lancer dans une forme rudimentaire pendant même que le compilateur est en train de construire le contexte de l'interpréteur. En fait, c'est précisément ce qui arrive lorsque le compilateur appelle l'interpréteur pour exécuter des blocs BEGIN et d'autres choses dans le même genre. Et l'interpréteur peut se retourner et utiliser le compilateur pour se construire davantage. Chaque fois que vous définissez un autre sous-programme ou que vous chargez un autre module, la machine virtuelle Perl particulière que nous appelons un interpréteur se redéfinit elle-même. Vous ne pouvez pas vraiment dire si c'est le compilateur ou l'interpréteur qui a le contrôle, car ils coopèrent pour contrôler le processus d'amorçage (bootstrap process) que nous appelons communément « lancer un script Perl ». C'est comme lorsqu'on amorce le cerveau d'un enfant. Est-ce l'ADN qui le fait ou les neurones ? Un peu des deux, selon nous, avec quelques interventions de programmeurs externes.

Il est possible de lancer de multiples interpréteurs dans le même processus ; ils peuvent ou non partager des arbres syntaxiques, selon qu'ils ont démarré en clonant un interpréteur existant ou en construisant un nouvel interpréteur à partir de zéro. Il est également possible de lancer de multiples threads dans un seul interpréteur, auquel cas ils ne partagent pas seulement des arbres syntaxiques, mais également les symboles globaux — voir le chapitre 17, Threads.

Mais la plupart des programmes Perl n'utilisent qu'un seul interpréteur Perl pour exécuter leur code compilé. Et alors que vous pouvez lancer de multiples interpréteurs Perl indépendants dans un seul processus, l'API actuelle pour ceci n'est accessible qu'en C.(150) Chaque interpréteur Perl individuel joue le rôle d'un processus complètement séparé, mais ne coûte pas autant que la création d'un nouveau processus complet. C'est ainsi que l'extension mod_perl d'Apache obtient de telles performances : lorsque vous lancez un script CGI sous mod_perl, ce script a déjà été compilé en codes d'opération Perl, évitant ainsi le besoin de le recompiler — mais, ce qui est plus important encore, en évitant le besoin de démarrer un nouveau processus, ce qui constitue le véritable goulot d'étranglement. Apache initialise un nouvel interpréteur Perl dans un processus existant et passe à cet interpréteur le code précédemment compilé pour qu'il l'exécute. Bien entendu, c'est un peu plus compliqué que cela — c'est toujours un peu plus compliqué. Pour plus d'informations sur mod_perl, voir Writing Apache Modules with Perl and C (O'Reilly, 1999).

Plusieurs autres applications, comme nvi, vim et innd, peuvent intégrer des interpréteurs Perl ; nous ne pouvons pas espérer les lister toutes ici. Il existe un bon nombre de produits commerciaux qui ne font même pas la publicité pour le moteur Perl qu'ils ont intégré. Ils l'utilisent seulement en interne, car il accomplit leur travail avec classe.

Ainsi, si Apache peut compiler un programme Perl maintenant et l'exécuter plus tard, pourquoi pas vous ? Apache et d'autres programmes contenant des interpréteurs Perl intégrés le font facilement — ils ne stockent jamais l'arbre syntaxique dans un fichier externe. Si cette approche vous convient et que vous cela ne vous embête pas d'utiliser l'API C pour en bénéficier, vous pouvez faire la même chose. Voir le paragraphe « Intégrer du Perl » au chapitre 21, Mécanismes internes et accès externes pour apprendre comment accéder à Perl depuis une infrastructure C l'entourant.

Si vous ne voulez pas prendre cette route ou si vous avez d'autres besoins, vous disposez alors de plusieurs options. Au lieu d'alimenter immédiatement l'interpréteur Perl avec les codes d'opération issus du compilateur Perl, vous pouvez invoquer l'une des nombreuses autres sorties (backends). Ces sorties peuvent sérialiser et stocker les codes d'opération compilés dans un fichier externe ou même les convertir en deux variétés différentes de code C.

Merci de bien prendre conscience que les générateurs de code sont tous des utilitaires extrêmement expérimentaux qui ne devraient pas espérer fonctionner dans un environnement de production. En fait, ils ne devraient même pas espérer fonctionner dans un environnement de non-production, sauf peut-être une fois tous les 36 du mois. Maintenant que nous avons assez rabaissé vos illusions pour que toute réussite les surpasse nécessairement, nous pouvons vous parler en toute sécurité du fonctionnement des sorties du compilateur.

Certains des modules de sortie (backend) sont des générateurs de code, comme B::Bytecode, B::C et B::CC. Les autres sont réellement des analyseurs de code et des outils de débogage, comme B::Deparse, B::Lint et B::Xref. Au-delà de ces sorties, la distribution standard inclut plusieurs autres modules de bas niveau d'un intérêt potentiel pour ceux désirant devenir auteurs d'outils Perl de développement de code. D'autres modules de sortie peuvent être trouvés sur CPAN, comprenant (au moment ou ces lignes sont écrites) B::Fathom, B::Graph, B::JVM::Jasmin et B::Size.

Lorsque vous utilisez le compilateur Perl pour autre chose que l'alimentation de l'interpréteur, le module O (c'est-à-dire en utilisant le fichier O.pm) se tient entre le compilateur et les modules de sorties variés. Vous n'appelez pas les sorties directement : vous appelez plutôt la partie intermédiaire, qui à son tour appelle la sortie désignée. Ainsi, si vous aviez un module appelé B::Backend, vous l'invoqueriez dans un script donné de cette manière :

% perl -MO=Backend NOM_SCRIPT

Certaines sorties prennent des options, spécifiées comme ceci :

% perl -MO=Backend OPTS NOM_SCRIPT

Certaines sorties ont déjà leur propre frontal pour invoquer leurs parties intermédiaires pour vous afin que vous n'ayez pas à vous souvenir de leur M.O. En particulier, perlcc(1) invoque ce générateur de code, qui peut être encombrant à lancer.

Les trois sorties actuelles qui convertissent des codes d'opération Perl en un autre format sont toutes emphatiquement expérimentales. (Oui, nous l'avons déjà dit, mais nous ne voulons pas que vous l'oubliiez.) Même lorsqu'il arrive qu'ils produisent en sortie quelque chose qui se lance correctement, les programmes résultants peuvent prendre plus d'espace disque, plus de mémoire et plus de temps CPU qu'ils ne le feraient d'ordinaire. Ceci est un sujet encore en recherche et développement. Les choses vont s'améliorer.

18-5-a. Le générateur de bytecode▲

% perlcc -B script_src > script_pby

#!/usr/bin/perl
use ByteLoader 0.04;
PLBCi386-linux^@0.04^@^D^@^@^@^D^@^@^@0x1234^@^G
^C^@^@^@^@^F^A^C^A^@^@^@^G^@^C^B^@^@^@^G^@^C^C^@^@^@^G^@^C^D^
^@^@^G^@^C^E^@^@^@^G^@^C^F^@^@^@^G^@^C^G^@^@^@^G^@^C^H^@^@^@^
...

18-5-b. Les générateurs de code C▲

Le module O possède de nombreux modi operandi intéressants autres que l'alimentation des générateurs de codes désespérément expérimentaux. En fournissant un accès relativement indolore à la sortie du compilateur Perl, ce module facilite l'écriture d'autres outils ayant besoin de tout savoir à propos d'un programme Perl.

Le module B::Lint est ainsi baptisé d'après lint(1), le vérificateur de programmes C. Il inspecte les programmes à la recherche de constructions douteuses qui égarent souvent les débutants, mais qui, normalement, ne déclenchent pas d'avertissements. Appelez le module directement :

% perl -MO=Lint,all mon_prog

Seules quelques vérifications sont actuellement définies, comme l'emploi d'un tableau dans un contexte scalaire implicite, le fait de se fier à des variables par défaut et l'accès à des identificateurs d'un autre paquetage, commençant par _ (normalement privés). Voir B::Lint(3) pour plus de détails.

Le module B::Xref génère des listes avec les références croisées des déclarations et des utilisations de toutes les variables (à la fois globales et de portée lexicale), de tous les sous-programmes et des tous les formats dans un programme, répartis par fichier et par sous-programme. Appelez le module de cette manière :

% perl -MO=Xref mon_prog > mon_prog.pxref

Voici, par exemple, un extrait de compte-rendu :

Subroutine analyse_argv
Package (lexical)
    $allume           i113, 114
    $opt              i113, 114
    %config_getopt    i107, 113
    @args_config      i112, 114, 116, 116
Package Getopt::Long
    $ignorecase       101
    &GetOptions       &124
Package main
    $Options          123, 124, 141, 150, 165, 169
    %$Options         141, 150, 165, 169
    &verifie_lecture  &167
    @ARGV             121, 157, 157, 162, 166, 166

Ceci montre que la routine analyse_argv avait quatre variables lexicales propres ; elle accédait également à des identificateurs globaux des paquetages main et Getopt::Long.

Les nombres représentent les lignes où l'élément en question a été utilisé : un i au début, indique que cet élément est utilisé pour la première fois à ce numéro de ligne et un & au début signifie qu'un sous-programme a été appelé ici. Les déréférences sont listées séparément, c'est pourquoi figurent à la fois $Options et %$Options.

B::Deparse est un module offrant un affichage agréable (pretty printer) pouvant démystifier du code Perl et vous aider à comprendre quelles transformations l'optimisateur a effectué sur votre code. Par exemple, ceci montre les valeurs utilisées par défaut par Perl pour diverses constructions :

% perl -MO=Deparse -ne 'for (1 .. 10) { print if -t }'
LINE: while (defined($_ = <ARGV>)) {
    foreach $_ (1 .. 10) {
        print $_ if -t STDIN;
    }
}

L'option -p ajoute des parenthèses pour que vous puissiez voir l'idée que Perl se fait de la préséance :

% perl -MO=Deparse,-p -e 'print $a ** 3 + sqrt(2) / 10 ** -2 ** $c'
print((($a ** 3) + (1.4142135623731 / (10 ** (-(2 ** $c))))));

Vous pouvez utiliser -q pour voir en quelles opérations élémentaires les chaînes interpolées sont compilées :

% perl -MO=Deparse,-q -e '"Un $nom et quelques @ARGV\n"'
'Un ' . $nom . ' et quelques ' . join($", @ARGV) . "\n";

Et ceci montre comment Perl compile vraiment une boucle for avec trois arguments en une boucle while :

% perl -MO=Deparse,-x3 -e 'for ($i=0;$i<10;$i++) { $x++ }'
$i= 0;
while ($i < 10) {
    ++$x;
}
continue {
    ++$i
}

Vous pouvez même appeler B::Deparse sur un fichier de bytecode Perl produit par perlcc -B et B::Deparse le décompile alors pour vous. Cependant, lire des codes d'opération Perl sérialisés est peut-être un jeu d'enfant, mais ce n'est pas le cas lorsqu'il s'agit d'un cryptage élevé.

Il y a un temps pour penser à tout ; parfois ce temps est derrière nous et parfois il est devant. Parfois il se situe entre les deux. Perl ne prétend pas savoir quand penser, il offre donc au programmeur un certain nombre d'options pour qu'il lui dise quand il faut penser. D'autres fois, il sait qu'une certaine sorte de pensée est nécessaire, mais il n'a aucune idée de ce qu'il doit penser, il a donc besoin d'un moyen de le demander à votre programme. Votre programme répond à ce genre de questions en définissant des sous-programmes avec des noms appropriés à ce que Perl essaie de trouver.

Non seulement le compilateur peut appeler l'interpréteur lorsqu'il veut avancer dans sa pensée, mais l'interpréteur peut également appeler le compilateur en retour lorsqu'il veut réviser l'histoire. Votre programme peut utiliser plusieurs opérateurs pour rappeler le compilateur. Comme le compilateur, l'interpréteur peut également appeler des sous-programmes nommés lorsqu'il veut se renseigner sur certaines choses. À cause de tous ces échanges entre le compilateur, l'interpréteur et votre programme, vous devez être conscient des choses qui se passent et quand elles se passent. Nous parlerons tout d'abord du moment où les sous-programmes nommés sont déclenchés.

Au chapitre 10, Paquetages, nous avons vu comment un sous-programme AUTOLOAD d'un paquetage était déclenché lorsqu'une fonction indéfinie dans ce paquetage était appelée. Au chapitre 12, Objets, nous avons fait connaissance avec la méthode DESTROY qui est invoquée lorsque la mémoire occupée par un objet est sur le point d'être récupérée par Perl. Enfin au chapitre 14, Variables liées, nous avons abordé plusieurs fonctions appelées implicitement lorsqu'on accédait à une variable liée.

Ces sous-programmes suivent tous la convention selon laquelle, si un sous-programme est déclenché automatiquement par le compilateur ou l'interpréteur, nous écrivons son nom en majuscules. Associés avec les différentes étapes de la vie de votre programme, il existe quatre autres sous-programmes de ce type, appelés BEGIN, CHECK, INIT et END. Le mot-clef sub est optionnel devant leurs déclarations. Peut-être devraient-ils être plutôt appelés « blocs », car d'une certaine manière ils ressemblent plus à des blocs nommés qu'à de véritables sous-programmes.

Par exemple, au contraire des sous-programmes ordinaires, il n'y a aucun mal à déclarer ces blocs plusieurs fois, puisque Perl garde une trace du moment où les appeler, vous n'avez donc pas à les appeler par leur nom. (Ils se différencient également des sous-programmes ordinaires en ce que shift et pop se comportent comme si vous étiez dans le programme principal et manipulent donc @ARGV par défaut et non @_.)

Ces quatre types de blocs s'exécutent dans cet ordre :

BEGIN

• S'exécute ASAP (as soon as parsed(152)) à chaque fois qu'on les rencontre pendant la compilation et avant de compiler le reste du fichier.

CHECK

• S'exécute lorsque la compilation est achevée, mais avant que le programme ne démarre. (CHECK peut vouloir dire « checkpoint » (point de contrôle) ou « double-check » (double vérification) ou même simplement « stop ».)

INIT

• S'exécute au début de l'exécution, juste avant que le flux principal de votre programme ne commence.

END

• S'exécute à la fin de l'exécution, juste après que le programme a fini.

Si vous déclarez plus d'un de ces blocs avec le même nom, même dans des modules séparés, les BEGIN s'exécutent tous avant les CHECK, qui eux-mêmes s'exécutent tous avant les INIT, qui à leur tour s'exécutent tous avant les END — qui finalement sont les derniers à s'exécuter avant de mourir, après que votre programme a fini. De multiples BEGIN et INIT s'exécutent dans l'ordre dans lequel ils ont été déclarés (FIFO, first in, first out : premier arrivé, premier servi) et les CHECK et END s'exécutent dans l'ordre inverse dans lequel ils ont été déclarés (LIFO, last in, first out : dernier arrivé, premier servi).

Ceci est probablement plus clair avec une démonstration :

#!/usr/bin/perl -l
print   "démarre l'exécution principale ici\n";
die     "l'exécution principale meurt ici\n";
die     "XXX: jamais atteint\n";
END     { print "1er END: fini d'exécuter" }
CHECK   { print "1er CHECK: fini de compiler" }
INIT    { print "1er INIT: commence à exécuter" }
END     { print "2ème END: fini d'exécuter" }
BEGIN   { print "1er BEGIN: toujours en train de compiler" }
INIT    { print "2ème INIT: commence à exécuter" }
BEGIN   { print "2ème BEGIN: toujours en train de compiler" }
CHECK   { print "2ème CHECK: fini de compiler" }
END     { print "3ème END: fini d'exécuter" }

Lorsqu'il s'exécute, ce programme de démonstration affiche ceci :

1er BEGIN: toujours en train de compiler
2ème BEGIN: toujours en train de compiler
2ème CHECK: fini de compiler
1er CHECK: fini de compiler
1er INIT: commence à exécuter
2ème INIT: commence à exécuter
démarre l'exécution principale ici
l'exécution principale meurt ici
3ème END: fini d'exécuter
2ème END: fini d'exécuter
1er END: fini d'exécuter

Puisqu'un bloc BEGIN s'exécute immédiatement, il peut entrer dans les déclarations, les définitions et les importations de sous-programmes avant même que le reste du fichier ne soit compilé. Ceci peut altérer la manière dont le compilateur analyse le reste du fichier courant, tout particulièrement si vous importez des définitions de sous-programmes. Du moins, déclarer un sous-programme lui permet d'être utilisé comme un opérateur de liste, rendant les parenthèses optionnelles. Si le sous-programme importé est déclaré avec un prototype, les appels à ce sous-programme peuvent être analysés comme les fonctions internes et peuvent même supplanter les fonctions internes du même nom afin de leur donner une sémantique différente. La déclaration use n'est qu'un bloc BEGIN qui s'y croit.

Les blocs END, par contraste, s'exécutent aussi tard que possible : lorsque votre programme quitte l'interpréteur Perl, même si c'est le résultat d'un die non intercepté ou d'une autre exception fatale. Il existe deux situations dans lesquelles un bloc END (ou une méthode DESTROY) est court-circuité. Il ne s'exécute pas si, au lieu de se terminer, le processus courant se métamorphose d'un programme à un autre via exec. Un processus balayé de la surface de la Terre par un signal non intercepté court-circuite également ses routines END. (Voir le pragma use sigtrap décrit au chapitre 31, Modules de pragmas, pour un moyen facile de convertir les signaux interceptables en exceptions. Pour des informations générales sur les signaux, voir la section Signaux au chapitre 16, Communication interprocessus.) Pour éviter le traitement de tous les END, vous pouvez appeler POSIX::_exit ou faire un kill -9, $$ ou simplement exec de n'importe quel programme inoffensif, comme /bin/true sur les systèmes Unix.

À l'intérieur d'un bloc END, $? contient le statut avec lequel le programme va sortir en faisant exit. Vous pouvez modifier $? depuis l'intérieur du bloc END pour changer la valeur de sortie du programme. Faites attention au changement accidentel de $? en lançant un autre programme avec system ou des apostrophes inverses.

Si vous avez plusieurs blocs END à l'intérieur d'un fichier, ils s'exécutent dans l'ordre inverse de leur définition. C'est-à-dire que le dernier bloc END défini est le premier à s'exécuter lorsque votre programme a fini. Cette inversion permet aux blocs BEGIN et END correspondants d'être imbriqués comme vous le souhaiteriez, si vous les aviez associés par paires. Par exemple, si le programme principal et un module qu'il charge ont leur propre paire de sous-programmes BEGIN et END, comme ceci :

BEGIN { print "le programme principal a commencé" }
END { print "le programme principal a fini" }
use Module;

et dans ce module, vous avez ces déclarations :

BEGIN { print "le module a commencé" }
END { print "le module a fini" }

alors le programme principal sait que son BEGIN arrivera toujours en premier et son END toujours en dernier. (Oui, BEGIN est vraiment un bloc à la compilation, mais des arguments identiques s'appliquent à des paires de blocs INIT et END à l'exécution.) Ce principe est vrai récursivement pour tout fichier qui en inclut un autre lorsque les deux ont des déclarations comme celles-ci. Cette propriété d'imbrication implique que ces blocs fonctionnent bien en tant que constructeurs et destructeurs. Chaque module peut avoir ses propres fonctions d'initialisation et de démolition que Perl appellera automatiquement. De cette manière, le programmeur n'a pas à se se rappeler si une bibliothèque particulière est utilisée, ni quelle initialisation spéciale ou quel code de nettoyage doit être invoqué, ni quand l'invoquer. Les déclarations du module s'occupent de ces événements.

Si vous pensez à un eval CHAÎNE comme à un rappel (c'est-à-dire, un appel en arrière) du compilateur par l'interpréteur, alors vous pourriez penser à un BEGIN comme à un appel en avant de l'interpréteur par le compilateur. Les deux suspendent temporairement l'activité et basculent le mode d'opération. Lorsque nous disons qu'un bloc BEGIN s'exécute aussi tôt que possible, nous voulons dire qu'il s'exécute dès qu'il est complètement défini, avant même que le reste du fichier qui le contient ne soit analysé. Les blocs BEGIN sont par conséquent exécutés à la compilation, jamais à l'exécution. Une fois qu'un bloc BEGIN s'est exécuté, il devient immédiatement indéfini et le code qu'il a utilisé est renvoyé à l'espace mémoire de Perl. Vous ne pourriez pas appeler un bloc BEGIN comme un sous-programme même si vous essayiez, car à l'heure où vous le feriez, il serait déjà parti.

De même que les blocs BEGIN, les blocs INIT s'exécutent juste avant que l'exécution de Perl ne commence, dans un ordre FIFO ( first in, first out : premier arrivé, premier servi). Par exemple, les générateurs de codes documentés dans perlcc utilisent des blocs INIT pour initialiser et résoudre les pointeurs vers les XSUB. Les blocs INIT sont vraiment comme les blocs BEGIN, sauf qu'ils permettent au programmeur de distinguer les constructions qui se déroulent à la compilation de celles qui se produisent à l'exécution. Lorsque vous lancez un script directement, ceci n'est pas extrêmement important, car le compilateur est de toute façon invoqué à chaque fois ; mais lorsque la compilation est séparée de l'exécution, la distinction peut devenir cruciale. Le compilateur peut n'être invoqué qu'une seule fois et l'exécutable résultant peut l'être plusieurs fois.

De même que les blocs END, les blocs CHECK s'exécutent dès que la phase de compilation de Perl se finit, mais avant que la phase d'exécution ne commence, dans un ordre LIFO (last in, first out : dernier arrivé, premier servi). Les blocs CHECK sont utiles pour « libérer » le compilateur tout comme les blocs END sont utiles pour libérer votre programme. En particulier, les sorties (backends) utilisent toutes des blocs CHECK comme le point à partir duquel invoquer leurs générateurs de code respectifs. Tout ce qu'elles ont besoin de faire est de mettre un bloc CHECK dans leur propre module et il s'exécutera au moment approprié, vous n'avez donc pas à installer de CHECK dans votre programme. Pour cette raison, vous n'écrirez que très rarement un bloc CHECK vous-même, à moins que vous n'écriviez de tels modules.

Récapitulant tout ceci, le tableau 18-1 énumère les diverses constructions en détaillant le moment où elles compilent le code représenté par « . . . » et celui où elles l'exécutent.

Maintenant que vous connaissez la partition, nous espérons que vous serez capable de composer et de jouer vos morceaux de Perl avec plus d'assurance.

Il est heureux que Perl se soit développé dans le monde Unix, car cela signifie que sa syntaxe d'appel fonctionne assez bien sous les interpréteurs de commandes des autres systèmes d'exploitation. La plupart des interpréteurs de commandes savent comment traiter une liste de mots en arguments, et ne voient pas d'inconvénient à ce qu'un argument commence par un signe moins. Bien entendu, il existe cependant quelques cas où vous vous faites piéger lorsque vous passez d'un système à l'autre. Vous ne pouvez pas utiliser les apostrophes sous MS-DOS comme vous le faites sous Unix, par exemple. Et sur les systèmes comme VMS, il est nécessaire d'employer un emballage logiciel (wrapper) sautant à travers divers cerceaux pour émuler l'indirection des entrées/sorties d'Unix. Nous posons notre joker quant à l'interprétation des jokers (wildcards). Mais une fois ces problèmes résolus, Perl traite ses options et ses arguments à peu près de la même manière sur n'importe quel système d'exploitation.

Même lorsque vous ne disposez pas d'un interpréteur de commandes per se, il est assez facile d'exécuter un programme Perl depuis un autre programme, écrit dans n'importe quel langage. Le programme appelant peut non seulement passer des arguments de la manière traditionnelle, mais il peut également passer des informations via des variables d'environnement et, si votre système d'exploitation l'implémente, des descripteurs de fichiers hérités (voir Passage de handles de fichiers au chapitre 16, Communication interprocessus). Même des mécanismes de passage d'argument plus exotiques peuvent facilement être encapsulés dans un module, amenés ensuite dans votre programme Perl via une simple directive use.

Perl analyse les options de la ligne de commande de la manière standard.(153) C'est-à-dire qu'il s'attend à ce que les options (les mots commençant par un moins) viennent en premier sur la ligne de commande. Le nom du script vient généralement ensuite, suivi par les arguments additionnels à passer au script. Certains de ces arguments supplémentaires peuvent eux-mêmes ressembler à des options, auquel cas ils doivent être traités par le script, car Perl abandonne l'analyse des options dès qu'il voit une non-option, ou l'option spéciale « - » qui vaut dire « Je suis la dernière option ».

Perl vous procure une certaine souplesse en ce qui concerne ce que vous fournissez au programme. Pour les petites tâches rapides et brouillonnes, vous pouvez programmer Perl entièrement depuis la ligne de commande. Pour les travaux plus importants, plus permanents, vous pouvez fournir un script Perl dans un fichier séparé. Perl recherche à compiler et à lancer un script que vous pouvez spécifier avec l'une de ces trois manières :

1. Spécifié ligne par ligne via des options -e sur la ligne de commande. Par exemple :

    

   Sélectionnez

   % perl -e "print 'Salut, tout le monde.'"
   Salut, tout le monde.

2. Contenu dans le fichier spécifié par le premier nom de fichier sur la ligne de commande. Les systèmes supportant la notation #! sur la première ligne d'un script exécutable invoquent les interpréteurs de cette façon à votre insu.

3. Passé implicitement via l'entrée standard. Cette méthode ne fonctionne que s'il n'y a pas de noms de fichier en argument ; pour passer des arguments à un script en entrée standard, vous devez utiliser la méthode 2, spécifier explicitement un « -» pour le nom du script. Par exemple :

% echo "print qq(Salut, @ARGV.)" | perl -tout le monde
Salut, tout le monde.

Avec les méthodes 2 et 3, Perl commence par analyser le fichier d'entrée depuis le début — à moins d'avoir spécifié l'option -x, ce qui lui fait rechercher la première ligne commençant par #! contenant le mot « perl », d'où il démarre. Cela sert à lancer un script inclus dans un message plus grand. En ce cas, vous pourriez indiquer la fin du script par le token __END__.

Que vous utilisiez ou non -x, la ligne #! est toujours examinée pour y trouver des options au moment de l'analyse syntaxique de la ligne. Ainsi, si vous vous trouvez sur une plate-forme qui n'autorise qu'un argument sur la ligne #! ou pis, qui ne reconnaît même pas la ligne #! comme étant spéciale, vous pouvez toujours conserver un comportement cohérent des options, quelle que soit la manière dont Perl est invoqué, même si -x a été utilisé pour trouver le début du script.

Attention : comme les versions plus anciennes d'Unix interrompent sans rien dire l'interprétation par le noyau de la ligne #! après 32 caractères, certaines options peuvent traiter votre programme correctement ou non ; vous pourriez même obtenir un « - » sans sa lettre, si vous n'êtes pas prudent. Assurez-vous que tous vos scripts tombent avant ou après cette limite de 32 caractères. La plupart des options ne se soucient pas d'être traitées plusieurs fois, mais un « - » au lieu d'une option complète pousserait Perl à essayer de lire son code source depuis l'entrée standard plutôt que depuis votre script. Et une option -I tronquée pourrait également provoquer des résultats étranges. Toutefois, certaines options tiennent compte du fait qu'elles soient traitées deux fois, comme les combinaisons de -l et de -0. Mettez toutes les options après la limite de 32 caractères (le cas échéant) ou remplacez l'emploi de -0CHIFFRES par BEGIN{$/ = "\0CHIFFRES";}. Évidemment, si vous n'êtes pas sur un système UNIX, vous êtes sûr de ne pas avoir ce genre de problème.

L'analyse des options sur la ligne #! démarre après que « perl » est mentionné pour la première fois. Les séquences « -* » et « - » sont spécifiquement ignorées au bénéfice des utilisateurs d'emacs et, si vous vous en sentez l'envie, vous pouvez écrire :

#!/bin/sh --# -*-perl -*- -p
eval 'exec perl $0 -S ${1+"$@"}'
    if 0;

et Perl ne verra que l'option -p. La jolie séquence « -*-perl -*- » indique à emacs de démarrer en mode Perl ; elle n'est pas nécessaire si vous n'utilisez pas emacs. Le sale -S est expliqué plus loin dans la description de cette option.

Une astuce identique met en jeu le programme env(1), si vous en disposez :

#!/usr/bin/env perl

Les exemples précédents utilisent un chemin relatif jusqu'à l'interpréteur Perl, obtenant ainsi la version trouvée en premier dans le chemin de l'utilisateur. Si vous voulez une version particulière de Perl, écrivez, perl5.6.1 et placez ceci directement dans le chemin de la ligne #!, soit avec le programme env, soit avec le sale -S, soit avec un traitement ordinaire de #!.

Si la ligne #! ne contient pas le mot « perl », le programme cité après le #! est exécuté à la place de l'interpréteur Perl. Par exemple, supposons que vous ayez ici un script ordinaire pour le Bourne shell qui dirait :

#!/bin/sh
echo "Je suis un script shell"

Si vous donnez ce fichier à Perl, celui-ci lancera /bin/sh pour vous. C'est un peu bizarre, mais cela facilite la vie à ceux dont les machines ne reconnaissent pas #!, parce qu'ils peuvent — en positionnant leur variable d'environnement SHELL — indiquer à un programme (comme un gestionnaire de courrier) que leur shell est /usr/bin/perl et Perl enverra le programme à l'interpréteur qui leur convient, même si leur noyau est trop stupide pour le faire tout seul.

Mais revenons aux scripts Perl qui sont vraiment des scripts Perl. Après avoir localisé votre script, Perl compile le programme complet sous une forme interne (voir le chapitre 18, Compilation). S'il y a une erreur de compilation, l'exécution du script n'est même pas lancée. (Au contraire du script shell typique ou du fichier de commande, qui pourrait s'exécuter partiellement avant de trouver une erreur de syntaxe.) Si le script est syntaxiquement correct, il est exécuté. S'il arrive à la fin sans avoir rencontré un opérateur exit ou die, un exit(0) implicite est fourni par Perl pour indiquer le succès de l'opération à celui qui vous appelait. (Au contraire du programme C typique, où vous êtes susceptible d'obtenir un statut de sortie aléatoire si votre programme ne fait que se terminer de la manière normale.)

19-1-a. #! et isolement (quotation) sur les systèmes non-Unix▲

extproc perl -S -vos_options

$ perl -mesopt 'f$env("procedure")' 'p1' 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8' !
$ exit++ + ++$status != 0 and $exit = $status = undef;

% perl -e 'print "Salut tout le monde\n"'

print "Salut tout le monde\n"

$ perl -e "print ""Salut tout le monde\n"""

$ perl -e "print qq(Salut tout le monde\n)"

A:> perl -e "print \"Salut tout le monde\n\""

A:> perl -e "print qq(Salut tout le monde\n)"

perl -e "print <Ctrl-x>"Salut tout le monde\n<Ctrl-x>""

19-1-b. Emplacement de Perl▲

#!/usr/local/bin/perl5.6.0

use v5.6.0;

19-1-c. Options▲

#!/usr/bin/perl -spi.bak # comme -s -p -i.bak

% find . -name '*.bak' -print0 | perl -n0e unlink

% perl -ane 'print pop(@F), "\n";'

while (<>) {
    @F = split(' ');
    print pop(@F), "\n";
}

% awk -F: '$7 && $7 !~ /^\/bin/' /etc/passwd
% perl -F: -lane 'print if $F[6] && $F[6] !~ m(^/bin)' /etc/passwd

BEGIN { $^C = 0; exit; }

# Syntaxe du Bourne shell
$ PERLDB_OPTS="NonStop=1 AutoTrace=1 frame=2" perl -dS programme

# Syntaxe de csh
% (setenv PERLDB_OPTS "NonStop=1 AutoTrace=1 frame=2"; perl -dS programme)

$ perl -e 'print "Salut, ";
          print "@ARGV !\n";' la compagnie
Salut, la compagnie !

% perl -e 'print "Salut, ";' \
       -e 'print "@ARGV !\n";' la compagnie
Salut, la compagnie !

($sauvegarde = $extension) =~ s/\*/$nom_fichier/g;

% perl -pi'orig_*' -e 's/truc/machin/' xyz # sauvegarde dans 'orig_xyz'

% perl -pi'ancien/*.orig' -e 's/truc/machin/' xyz # sauvegarde dans
'ancien/xyz.orig'

% perl -pi -e 's/truc/machin/' xyz         # écrase le fichier actuel
% perl -pi'*' -e 's/truc/machin/' xyz      # écrase le fichier actuel

% perl -pi'.orig' -e 's/truc/machin/' xyz  # sauvegarde dans 'xyz.orig'
% perl -pi'*.orig' -e 's/truc/machin/' xyz # sauvegarde dans 'xyz.orig'

% perl -p -i.orig -e "s/truc/machin/;"

#!/usr/bin/perl -pi.orig
s/truc/machin/;

#!/usr/bin/perl
$extension = '.orig';
LIGNE: while (<>) {
    if ($ARGV ne $ancien_argv) {
        if ($extension !~ /\*/) {
            $sauvegarde = $ARGV . $extension;
        }
        else {
            ($sauvegarde = $extension) =~ s/\*/$ARGV/g;
        }
        unless (rename($ARGV, $sauvegarde)) {
            warn "impossible de renommer $ARGV en $sauvegarde : $!\n";
            close ARGV;
            next;
        }
        open(ARGV_SORTIE, ">$ARGV");
        select(ARGV_SORTIE);
        $ancien_argv = $ARGV;
    }
    s/truc/machin/;
}
continue {
    print; # ceci écrit dans le fichier de nom original
}
select(STDOUT);

% perl -pi~ -e 's/truc/machin/' fichier1 fichier2 fichier3...

% perl -lpe 'substr($_, 80) = ""'

% gnufind / -print0 | perl -ln0e 'print "trouvé $_" if -p'