perlfork - En ligne dans le Cloud

PROGRAMME:

Nom

perlfork - Émulation fork() de Perl

SYNOPSIS

REMARQUE : à partir de la version 5.8.0, l'émulation fork() a considérablement
mûri. Cependant, il existe encore quelques bugs et différences connus.
provenant d'un fork() réel qui pourrait vous affecter. Consultez les « BUGS » et
Sections « MISES EN GARDE ET LIMITATIONS » ci-dessous.

Perl fournit un fourchette() mot-clé correspondant à l'appel système Unix du même nom.
Sur la plupart des plates-formes de type Unix où le fourchette() l'appel système est disponible, celui de Perl fourchette()
l'appelle simplement.

Sur certaines plates-formes telles que Windows où le fourchette() l'appel système n'est pas disponible, Perl peut
être construit pour imiter fourchette() au niveau de l'interpréteur. Bien que l'émulation soit conçue pour
être aussi compatible que possible avec le réel fourchette() au niveau du programme Perl, il y a
il y a certaines différences importantes qui découlent du fait que tous les pseudo-enfants
les « processus » créés de cette manière vivent dans le même processus réel que le système d'exploitation
est concerné.

Ce document fournit un aperçu général des capacités et des limites du
fourchette() émulation. Notez que les problèmes abordés ici ne s'appliquent pas aux plateformes
où un vrai fourchette() est disponible et Perl a été configuré pour l'utiliser.

DESCRIPTION

Le manuel de formation fourchette() L'émulation est implémentée au niveau de l'interpréteur Perl. Ce que cela signifie
en général, c'est courir fourchette() clonera en fait l'interpréteur en cours d'exécution et tous ses
état et exécutez l'interpréteur cloné dans un thread séparé, en commençant l'exécution dans le nouveau
fil juste après le point où le fourchette() a été appelé dans le parent. Nous ferons référence à
le thread qui implémente ce « processus » enfant en tant que pseudo-processus.

Au programme Perl qui a appelé fourchette(), tout cela est conçu pour être transparent.
le parent revient de la fourchette() avec un pseudo-ID de processus qui peut être utilisé ultérieurement dans
toutes les fonctions de manipulation de processus ; l'enfant revient du fourchette() avec une valeur de 0 à
signifie qu'il s'agit du pseudo-processus enfant.

Comportement of d’autres Perl Caractéristiques in à bifurcation pseudo-processus
La plupart des fonctionnalités de Perl se comportent de manière naturelle au sein des pseudo-processus.

$$ ou $PROCESS_ID
Cette variable spéciale est correctement définie sur l'ID du pseudo-processus. Elle peut être utilisée.
pour identifier les pseudo-processus au sein d'une session particulière. Notez que cette valeur est
sujet au recyclage si des pseudo-processus sont lancés après que d'autres ont été
attendre()-ed sur.

%ENV Chaque pseudo-processus maintient son propre environnement virtuel. Modifications apportées à %ENV
affectent l'environnement virtuel et ne sont visibles qu'au sein de ce pseudo-processus,
et dans tous les processus (ou pseudo-processus) lancés à partir de celui-ci.

chdir() et tous les autres éléments intégrés qui acceptent les noms de fichiers
Chaque pseudo-processus conserve sa propre idée virtuelle du répertoire courant.
Modifications apportées au répertoire courant à l'aide de chdir() ne sont visibles qu'à l'intérieur de cela
pseudo-processus, et dans tous les processus (ou pseudo-processus) lancés à partir de celui-ci. Tous
les accès aux fichiers et aux répertoires à partir du pseudo-processus mapperont correctement le virtuel
répertoire de travail vers le répertoire de travail réel de manière appropriée.

attendre() et pid d'attente ()
attendre() et pid d'attente () peut être transmis un pseudo-ID de processus renvoyé par fourchette(). Ces
les appels attendront correctement la fin du pseudo-processus et renverront son
état.

tuer() "kill('KILL', ...)" peut être utilisé pour terminer un pseudo-processus en lui passant l'ID
retourné par fourchette(). Le résultat de la destruction d'un pseudo-processus est imprévisible et
il ne doit pas être utilisé sauf dans des circonstances extrêmes, car le système d'exploitation
le système peut ne pas garantir l'intégrité des ressources du processus lorsqu'un thread est en cours d'exécution
est terminé. Le processus implémentant les pseudo-processus peut être bloqué.
et l'interpréteur Perl se bloque. Notez que l'utilisation de « kill('KILL', ...) » sur une
pseudo-traiter() peut généralement provoquer des fuites de mémoire, car le thread qui
implémente le pseudo-processus n'a pas la possibilité de nettoyer ses ressources.

"kill('TERM', ...)" peut également être utilisé sur des pseudo-processus, mais le signal ne le sera pas
être délivré pendant que le pseudo-processus est bloqué par un appel système, par exemple en attente
pour qu'une socket se connecte ou pour essayer de lire à partir d'une socket sans données disponibles.
À partir de Perl 5.14, le processus parent n'attendra plus que les enfants se terminent une fois
ils ont été signalés avec "kill('TERM', ...)" pour éviter un blocage pendant le processus
sortie. Vous devrez appeler explicitement pid d'attente () pour s'assurer que l'enfant a du temps
de se nettoyer, mais vous êtes alors également responsable que l'enfant ne soit pas
blocage sur les E/S non plus.

exécutable() appel exécutable() dans un pseudo-processus génère en fait l'exécutable demandé dans
un processus distinct et attend qu'il soit terminé avant de quitter avec la même sortie
statut de ce processus. Cela signifie que l'ID de processus indiqué dans le
l'exécution de l'exécutable sera différente de celle du Perl précédent fourchette() pourrait avoir
renvoyé. De même, toute fonction de manipulation de processus appliquée à l'ID
retourné par fourchette() affectera le pseudo-processus en attente qui a appelé exécutable(), Pas
le véritable processus qu'il attend après le exécutable().

Quand exécutable() est appelé à l'intérieur d'un pseudo-processus puis détruit les méthodes et termine les blocs
sera toujours appelé après le retour du processus externe.

sortie() sortie() quitte toujours uniquement le pseudo-processus en cours d'exécution, après avoir automatiquement
attendre()-ing pour tout pseudo-processus enfant en attente. Notez que cela signifie que
le processus dans son ensemble ne se terminera pas à moins que tous les pseudo-processus en cours d'exécution n'aient
terminé. Voir ci-dessous certaines limitations concernant les handles de fichiers ouverts.

Ouvrir les poignées des fichiers, des répertoires et des sockets réseau
Toutes les poignées ouvertes sont dup()-ed dans les pseudo-processus, de sorte que la fermeture de tous les handles dans
Un processus n'affecte pas les autres. Voir ci-dessous pour certaines limitations.

Ressources limites
Aux yeux du système d’exploitation, les pseudo-processus créés via le fourchette() l'émulation sont
simplement des threads dans le même processus. Cela signifie que toute limite au niveau du processus imposée par
le système d'exploitation s'applique à tous les pseudo-processus pris ensemble. Cela inclut tous
limites imposées par le système d'exploitation sur le nombre de fichiers, de répertoires et de sockets ouverts
poignées, limites d'utilisation de l'espace disque, limites de taille de mémoire, limites d'utilisation du processeur, etc.

Meurtre le mère processus
Si le processus parent est tué (soit en utilisant Perl tuer() intégré ou en utilisant certains
(par des moyens externes) tous les pseudo-processus sont également tués et l'ensemble du processus se termine.

Durée de vie of le mère processus et pseudo-processus
Au cours du cours normal des événements, le processus parent et chaque pseudo-processus démarré par
il attendra que leurs pseudo-enfants respectifs soient terminés avant de quitter.
signifie que le parent et chaque pseudo-enfant créé par lui qui est également un pseudo-parent
ne sortiront qu'après que leurs pseudo-enfants seront sortis.

À partir de Perl 5.14, un parent ne sera pas attendre() automatiquement pour tout enfant qui a été
signalé avec "kill('TERM', ...)" pour éviter un blocage au cas où l'enfant bloquerait
E/S et ne reçoit jamais le signal.

MISES EN GARDE ET LIMITATIONS

blocs BEGIN
Le manuel de formation fourchette() l'émulation ne fonctionnera pas entièrement correctement lorsqu'elle sera appelée depuis un
Bloc BEGIN. La copie dupliquée exécutera le contenu du bloc BEGIN, mais
Ne pas poursuivre l'analyse du flux source après le bloc BEGIN. Par exemple,
considérez le code suivant :

COMMENCER {
fork et exit ; # fork enfant et exit parent
imprimer "inner\n";
}
imprimer "outer\n";

Cela imprimera:

intérieur

plutôt que l'attendu :

intérieur
extérieur

Cette limitation découle de difficultés techniques fondamentales liées au clonage et
redémarrer les piles utilisées par l'analyseur Perl au milieu d'une analyse.

Ouvrir les handles de fichiers
Tous les fichiers ouverts au moment de l' fourchette() sera dup()-éd. Ainsi, les fichiers
peut être fermé indépendamment dans le parent et l'enfant, mais attention, dup()-ed
Les poignées partageront toujours le même pointeur de recherche. La modification de la position de recherche dans le
Le parent le modifiera dans l'enfant et vice-versa. On peut éviter cela en ouvrant
fichiers qui nécessitent des pointeurs de recherche distincts séparément dans l'enfant.

Sur certains systèmes d'exploitation, notamment Solaris et Unixware, l'appel de « exit() » à partir d'un
le processus enfant videra et fermera les handles de fichiers ouverts dans le parent,
Corruption des handles de fichiers. Sur ces systèmes, il est recommandé d'appeler « _exit() ».
à la place. « _exit() » est disponible en Perl via le module « POSIX ». Veuillez
consultez les pages de manuel de votre système pour plus d'informations à ce sujet.

Ouvrir les poignées de répertoire
Perl lira complètement tous les descripteurs de répertoires ouverts jusqu'à ce qu'ils atteignent la fin
du flux. Il sera alors chercherdir() retour à l'emplacement d'origine et tout
avenir readdir () Les requêtes seront traitées à partir du tampon cache. Cela signifie
que ni le handle de répertoire détenu par le processus parent ni celui détenu par
le processus enfant verra toutes les modifications apportées au répertoire après le fourchette()
appel.

Notez que rebobiner() a une limitation similaire sur Windows et ne forcera pas
readdir () pour relire le répertoire. Seul un répertoire nouvellement ouvert
handle reflétera les modifications apportées au répertoire.

Tuyau fourchu ouvrir() Pas encore implémenté
Les constructions « open(FOO, "|-") » et « open(BAR, "-|") » ne sont pas encore implémentées.
Cette limitation peut être facilement contournée dans un nouveau code en créant un tube
explicitement. L'exemple suivant montre comment écrire dans un enfant forké :

# simuler open(FOO, "|-")
sous-pipe_to_fork ($) {
mon $parent = shift;
envoie un tuyau à mon $enfant, $parent ou meurs ;
mon $pid = fork();
die "fork() a échoué : $!" sauf si défini $pid ;
si ($pid) {
fermer $child;
}
else {
fermer $parent;
ouvrir(STDIN, "<&=" . fileno($child)) ou mourir ;
}
$pid;
}

si (pipe_to_fork('FOO')) {
# parent
imprimer FOO "pipe_to_fork\n";
fermer FOO;
}
else {
# enfant
tandis que ( ) { imprimer; }
sortie(0);
}

Et celui-ci lit de la bouche de l'enfant :

# simuler open(FOO, "-|")
sous-pipe_from_fork ($) {
mon $parent = shift;
pipe $parent, mon $enfant ou meurs ;
mon $pid = fork();
die "fork() a échoué : $!" sauf si défini $pid ;
si ($pid) {
fermer $child;
}
else {
fermer $parent;
ouvrir(STDOUT, ">&=" . fileno($child)) ou mourir ;
}
$pid;
}

si (pipe_from_fork('BAR')) {
# parent
alors que ( ) { imprimer; }
fermer BAR;
}
else {
# enfant
imprimer "pipe_from_fork\n";
sortie(0);
}

Tuyau fourchu ouvrir() les constructions seront prises en charge à l'avenir.

État global maintenu par les XSUB
Les sous-routines externes (XSUB) qui maintiennent leur propre état global peuvent ne pas fonctionner
correctement. Ces XSUB devront soit maintenir des verrous pour protéger les accès simultanés
accéder aux données globales de différents pseudo-processus, ou maintenir tous leurs états
sur la table des symboles Perl, qui est copiée naturellement lorsque fourchette() est appelé. Un
mécanisme de rappel qui offre aux extensions la possibilité de cloner leur état
sera fourni dans un avenir proche.

Interprète intégré dans une application plus vaste
Le manuel de formation fourchette() l'émulation peut ne pas se comporter comme prévu lorsqu'elle est exécutée dans un
application qui intègre un interpréteur Perl et appelle des API Perl capables d'évaluer
des fragments de code Perl. Cela vient du fait que l'émulation ne connaît que
sur les propres structures de données de l'interpréteur Perl et ne sait rien sur les
contenant l'état de l'application. Par exemple, tout état reporté sur
la pile d'appels de l'application est hors de portée.

Sécurité des threads des extensions
Depuis l' fourchette() l'émulation exécute le code dans plusieurs threads, les extensions appelant
les bibliothèques non thread-safe peuvent ne pas fonctionner de manière fiable lors de l'appel fourchette(). Comme Perl
La prise en charge du threading devient progressivement plus largement adoptée, même sur les plateformes dotées d'un
indigène fourchette(), de telles extensions devraient être corrigées pour des raisons de sécurité des threads.

PORTABILITÉ MISES EN GARDE

Dans le code Perl portable, « kill(9, $child) » ne doit pas être utilisé sur les processus forkés. Tuer un
Le processus dérivé est dangereux et produit des résultats imprévisibles. Voir « tuer()", au-dessus de.

Utiliser perlfork en ligne avec les services onworks.net