erl - En ligne dans le Cloud

PROGRAMME:

Nom

erl - L'émulateur Erlang

DESCRIPTION

Notre erl programme démarre un système d'exécution Erlang. Les détails exacts (par exemple, si
erl est un script ou un programme et quels autres programmes il appelle) dépendent du système.

Les utilisateurs de Windows veulent probablement utiliser le Werl programme à la place, qui s'exécute dans sa propre fenêtre
avec des barres de défilement et prend en charge l'édition en ligne de commande. Les erl programme sur Windows ne fournit pas
l'édition de ligne dans son shell, et sur Windows 95, il n'y a aucun moyen de revenir au texte qui
a défilé hors de l'écran. Les erl doit être utilisé, cependant, dans des pipelines ou si vous
souhaitez rediriger l'entrée ou la sortie standard.

Attention:
À partir de la version ERTS 5.9 (OTP-R15B), le système d'exécution sera par défaut pas lier les planificateurs
aux processeurs logiques. Pour plus d'informations, voir la documentation du +sbt indicateur du système.

Les exportations

erl

Démarre un système d'exécution Erlang.

Les arguments peuvent être divisés en émule drapeaux, drapeaux et votre plaine arguments:

* Tout argument commençant par le caractère + est interprété comme un émule drapeau.

Comme indiqué par le nom, les indicateurs d'émulateur contrôlent le comportement de l'émulateur.

* Tout argument commençant par le caractère - (trait d'union) est interprété comme un drapeau
qui devrait être transmis à la partie Erlang du système d'exécution, plus
spécifiquement à la init processus système, voir init(3erl).

Notre init processus lui-même interprète certains de ces indicateurs, le init drapeaux. Elle
stocke tous les drapeaux restants, le utilisateur drapeaux. Ce dernier peut être récupéré par
appel init:get_argument/1.

On peut noter qu'il y a un petit nombre de drapeaux "-" qui maintenant en fait
sont des drapeaux d'émulateur, voir la description ci-dessous.

* Les arguments clairs ne sont en aucun cas interprétés. Ils sont également stockés par le
init processus et peut être récupéré en appelant init:get_plain_arguments/0. Plaine
les arguments peuvent se produire avant le premier indicateur, ou après un -- drapeau. En outre,
le drapeau -supplémentaire fait que tout ce qui suit devient de simples arguments.

Mise en situation :

% erl +W w -sname arnie +R 9 -s mon_init -extra +bertie
(arnie@host)1> init:get_argument(sname).
{d'accord,[["arnie"]]}
(arnie@host)2> init:get_plain_arguments().
["+bertie"]

Ici +W w et votre +R 9 sont des drapeaux d'émulateur. -s mon_init est un indicateur d'initialisation, interprété par
init. -Le nom de Arnie est un indicateur d'utilisateur, stocké par init. Il est lu par Kernel et sera
provoquer la distribution du système d'exécution Erlang. Enfin, tout après
-supplémentaire (C'est, +bertie) est considéré comme de simples arguments.

% erl -monflag 1
1> initialiser :obtenir_argument(mon drapeau).
{d'accord,[["1"]]}
2> init:get_plain_arguments().
[]

Ici le drapeau utilisateur -mon drapeau 1 est transmis et stocké par le init traiter. C'est un
indicateur défini par l'utilisateur, probablement utilisé par une application définie par l'utilisateur.

DRAPEAUX

Dans la liste suivante, les indicateurs d'initialisation sont marqués (indicateur d'initialisation). Sauf indication contraire, tous
les autres indicateurs sont des indicateurs utilisateur, pour lesquels les valeurs peuvent être récupérées en appelant
init:get_argument/1. Notez que la liste des drapeaux d'utilisateurs n'est pas exhaustive, il peut y avoir
des indicateurs supplémentaires spécifiques à l'application qui sont plutôt documentés dans le
dossier de candidature.

--(indicateur d'initialisation) :
Tout ce qui suit -- jusqu'au drapeau suivant (-drapeau or +drapeau) est considéré comme simple
arguments et peut être récupéré en utilisant init:get_plain_arguments/0.

-Application Par vague:
Définit le paramètre de configuration de l'application Par à la valeur vague pour la candidature
Application, Voir appli(5) et votre application(3erl).

-args_file FileName:
Les arguments de la ligne de commande sont lus à partir du fichier FileName. Les arguments lus dans le
fichier remplacer le '-args_file FileName' sur la ligne de commande résultante.

Le fichier FileName doit être un fichier texte brut et peut contenir des commentaires et des commandes
arguments de ligne. Un commentaire commence par un caractère # et continue jusqu'à la fin suivante de
caractère de ligne. La barre oblique inverse (\\) est utilisée comme guillemet. Toutes les lignes de commande
arguments acceptés par erl sont autorisés, ainsi que les -args_file FileName drapeau. Fais attention
ne pas provoquer de dépendances circulaires entre les fichiers contenant le -args_file drapeau,
cependant.

Notre -supplémentaire drapeau est traité spécialement. Sa portée se termine à la fin du fichier. Arguments
suite à un -supplémentaire drapeau sont déplacés sur la ligne de commande dans le -supplémentaire section, c'est-à-dire
la fin de la ligne de commande qui suit après un -supplémentaire drapeau.

-async_shell_start:
Le shell Erlang initial ne lit pas l'entrée de l'utilisateur tant que la procédure de démarrage du système n'a pas
été terminé (Erlang 5.4 et versions ultérieures). Ce drapeau désactive le démarrage de la synchronisation
et permet au shell de démarrer en parallèle avec le reste du système.

-démarrage Déposez votre dernière attestation :
Spécifie le nom du fichier de démarrage, Fichier.boot, qui est utilisé pour démarrer le système. Voir
init(3erl). À moins que Déposez votre dernière attestation contient un chemin absolu, le système recherche Fichier.boot
dans le courant et $RACINE/bac répertoires.

La valeur par défaut est $ROOT/bin/start.boot.

-var_boot Chaque Dir:
Si le script de démarrage contient une variable de chemin Chaque autre que $RACINE, cette variable est
étendu à Dir. Utilisé lorsque les applications sont installées dans un autre répertoire que
$RACINE/lib, Voir outils système:make_script/1,2.

-code_path_cache:
Active le cache du chemin de code du serveur de code, voir code(3erl).

-compiler Mod1 Mod2 :
Compile les modules spécifiés puis se termine (avec un code de sortie différent de zéro si le
la compilation de certains fichiers n'a pas réussi). Implique -pas d'entrée. Non recommandé - utiliser
erlc à la place.

-config Config:
Indique le nom d'un fichier de configuration, Config.config, qui est utilisé pour configurer
applications. Voir appli(5) et votre application(3erl).

-connect_all non:
Si ce drapeau est présent, de défis ne maintiendra pas un réseau entièrement connecté de
les nœuds Erlang distribués, puis l'enregistrement de nom global ne peut pas être utilisé. Voir
de défis(3erl).

-biscuit Cookies:
Indicateur obsolète sans aucun effet et faute d'orthographe courante pour -setcookie. utilisation -setcookie
à la place.

-détaché:
Démarre le système d'exécution Erlang détaché de la console système. Utile pour courir
démons et processus d'arrière-plans. Implique -pas d'entrée.

-emu_args:
Utile pour le débogage. Imprime les arguments réels envoyés à l'émulateur.

-env Variable Valeur:
Définit la variable d'environnement du système d'exploitation hôte Variable à la valeur Valeur pour l'Erlang
système d'exécution. Exemple:

% erl -env AFFICHAGE gin:0

Dans cet exemple, un système d'exécution Erlang est démarré avec le DISPLAY sûr, heureux et sain
variable définie sur gin:0.

-évaluation Expr(indicateur d'initialisation) :
Donne init évaluer l'expression Expr, Voir init(3erl).

-supplémentaire(indicateur d'initialisation) :
Tout ce qui suit -supplémentaire est considéré comme des arguments simples et peut être récupéré en utilisant
init:get_plain_arguments/0.

-cœur:
Démarre la surveillance du rythme cardiaque du système d'exécution Erlang. Voir Cœur(3erl).

-caché:
Démarre le système d'exécution Erlang en tant que nœud caché, s'il est exécuté en tant que nœud distribué.
Les nœuds cachés établissent toujours des connexions cachées avec tous les autres nœuds, à l'exception des nœuds
dans le même groupe mondial. Les connexions masquées ne sont publiées sur aucun des
nœuds connectés, c'est-à-dire qu'aucun des nœuds connectés ne fait partie du résultat de
nœuds/0 sur l'autre nœud. Voir aussi les groupes globaux masqués, groupe_global(3erl).

-hôtes Hôtes:
Spécifie les adresses IP des hôtes sur lesquels les serveurs de démarrage Erlang s'exécutent, voir
erl_boot_server(3erl). Ce drapeau est obligatoire si le -chargeur inet le drapeau est présent.

Les adresses IP doivent être données sous la forme standard (quatre nombres décimaux séparés par
périodes, par exemple "150.236.20.74". Les noms d'hôtes ne sont pas acceptables, mais une diffusion
l'adresse (de préférence limitée au réseau local) est.

-identifiant Id:
Spécifie l'identité du système d'exécution Erlang. S'il est exécuté en tant que
nœud, Id doit être identique au nom fourni avec le -Le nom de or -patate douce
drapeau.

-init_debug:
Donne init écrivez des informations de débogage tout en interprétant le script de démarrage.

-instr(drapeau de l'émulateur) :
Sélectionne un système d'exécution Erlang instrumenté (machine virtuelle) à exécuter, au lieu du
un ordinaire. Lors de l'exécution d'un système d'exécution instrumenté, certaines données d'utilisation des ressources
peuvent être obtenus et analysés à l'aide du module instrument. Fonctionnellement, il se comporte
exactement comme un système d'exécution Erlang ordinaire.

-chargeur Chargeur:
Spécifie la méthode utilisée par erl_prim_loader pour charger les modules Erlang dans le système.
See erl_prim_loader(3erl). Deux Chargeur les méthodes sont supportées, TED et votre inet. TED
signifie utiliser le système de fichiers local, c'est la valeur par défaut. inet signifie utiliser un serveur de démarrage sur
une autre machine, et le -identifiant, -hôtes et votre -setcookie Les drapeaux doivent également être spécifiés.
If Chargeur est autre chose, l'utilisateur a fourni Chargeur le programme de port est lancé.

-faire:
Fait appeler le système d'exécution Erlang fait tout() dans le répertoire de travail courant et
puis terminer. Voir a prendre une(3erl). Implique -pas d'entrée.

-homme Module:
Affiche la page de manuel du module Erlang Module. Uniquement pris en charge sur Unix.

-mode Interactif | intégré:
Indique si le système doit charger le code dynamiquement (Interactif), ou si tout le code
doit être chargé lors de l'initialisation du système (intégré), voir code(3erl). Par défaut à
Interactif.

-patate douce Nom:
Transforme le système d'exécution Erlang en un nœud distribué. Ce drapeau invoque tous les réseaux
serveurs nécessaires pour qu'un nœud soit distribué. Voir net_kernel(3erl). C'est aussi
assuré que epmd s'exécute sur l'hôte actuel avant le démarrage d'Erlang. Voir epmd(1).

Le nom du nœud sera Nom@Hôte, Où Hôte est le nom d'hôte complet de
l'hôte actuel. Pour les noms courts, utilisez le -Le nom de drapeau à la place.

-pas d'entrée:
Garantit que le système d'exécution Erlang n'essaie jamais de lire une entrée. Implique
-pas de coquille.

-pas de coquille:
Démarre un système d'exécution Erlang sans shell. Ce drapeau permet d'avoir le
Système d'exécution Erlang en tant que composant d'une série de tuyaux UNIX.

-pas de bâton:
Désactive la fonction de répertoire persistant du serveur de code Erlang, voir code(3erl).

-vieille coquille:
Invoque l'ancien shell Erlang d'Erlang 3.3. L'ancien shell peut toujours être utilisé.

-Pennsylvanie Rép1 Rép2 :
Ajoute les répertoires spécifiés au début du chemin de code, similaire à
code : add_pathsa/1. Voir code(3erl). Comme alternative à -Pennsylvanie, si plusieurs répertoires
doivent être ajoutés au chemin du code et les répertoires ont un parent commun
répertoire, ce répertoire parent pourrait être spécifié dans le ERL_LIBS sûr, heureux et sain
variable. Voir code(3erl).

-pz Rép1 Rép2 :
Ajoute les répertoires spécifiés à la fin du chemin de code, similaire à
code : add_pathsz/1. Voir code(3erl).

-chemin Rép1 Rép2 :
Remplace le chemin spécifié dans le script de démarrage. Voir scénario(5).

-proto_dist Proto:
Spécifiez un protocole pour la distribution Erlang.

inet_tcp:
TCP sur IPv4 (valeur par défaut)

inet_tls:
distribution sur TLS/SSL

inet6_tcp:
TCP sur IPv6

Par exemple, pour démarrer des nœuds distribués IPv6 :

% erl -nom [email protected] -proto_dist inet6_tcp

-remsh Nœud:
Démarre Erlang avec un shell distant connecté à Nœud.

-rsh Programme:
Spécifie une alternative à rsh pour démarrer un nœud esclave sur un hôte distant. Voir
esclave(3erl).

-courir Façon [Fonction [Arg1, Arg2, ...]](indicateur d'initialisation) :
Donne init appeler la fonction spécifiée. Func Par défaut Commencer. Si aucun argument n'est
pourvu, la fonction est supposée être d'arité 0. Sinon, elle est supposée être de
arité 1, en prenant la liste [Arg1,Arg2,...] comme argument. Tous les arguments sont passés comme
cordes. Voir init(3erl).

-s Façon [Fonction [Arg1, Arg2, ...]](indicateur d'initialisation) :
Donne init appeler la fonction spécifiée. Func Par défaut Commencer. Si aucun argument n'est
pourvu, la fonction est supposée être d'arité 0. Sinon, elle est supposée être de
arité 1, en prenant la liste [Arg1,Arg2,...] comme argument. Tous les arguments sont passés comme
atomes. Voir init(3erl).

-setcookie Cookies:
Définit le cookie magique du nœud sur Cookies, Voir Erlang:set_cookie/2.

-shutdown_time Heure:
Spécifie combien de temps (en millisecondes) le init processus est autorisé à passer
arrêt du système. Si Heure ms se sont écoulées, tous les processus encore existants sont
tué. Par défaut à infini.

-Le nom de Nom:
Transforme le système d'exécution Erlang en un nœud distribué, similaire à -patate douce, Mais l'
partie du nom d'hôte du nom de nœud Nom@Hôte sera le nom court, pas complètement
qualifié.

C'est parfois le seul moyen d'exécuter Erlang distribué si le DNS (Domain Name
System) n'est pas en cours d'exécution. Il ne peut y avoir de communication entre les nœuds fonctionnant avec le
-Le nom de drapeau et ceux qui courent avec le -patate douce flag, car les noms de nœuds doivent être uniques dans
systèmes Erlang distribués.

-smp [activer|auto|désactiver]:
-smp permettre et votre -smp démarre le système d'exécution Erlang avec la prise en charge SMP activée. Cette
peut échouer si aucun système d'exécution avec prise en charge SMP n'est disponible. -smp auto démarre le
Système d'exécution Erlang avec prise en charge SMP activée s'il est disponible et plusieurs
processeur logique sont détectés. -smp désactiver démarre un système d'exécution sans SMP
soutien.

REMARQUE: Le système d'exécution avec prise en charge SMP ne sera pas disponible sur tous les
plates-formes. Voir aussi le +S drapeau.

-version(drapeau de l'émulateur) :
Oblige l'émulateur à imprimer son numéro de version. Le même que erl +V.

ÉMULATEUR DRAPEAUX

erl invoque le code de l'émulateur Erlang (machine virtuelle), qui prend en charge le
drapeaux suivants :

+a Taille:
Taille de pile suggérée, en kilomots, pour les threads du pool de threads asynchrone. Plage valide
est de 16 à 8192 kilomots. La taille de pile suggérée par défaut est de 16 kilomots, c'est-à-dire 64
kilo-octet sur les architectures 32 bits. Cette petite taille par défaut a été choisie depuis la
la quantité de threads asynchrones peut être assez importante. La taille par défaut est suffisante pour les pilotes
livré avec Erlang/OTP, mais peut ne pas être suffisamment grand pour d'autres
liés dans les pilotes qui utilisent le pilote_async() Fonctionnalité. Notez que la valeur
passé n'est qu'une suggestion, et il peut même être ignoré sur certaines plateformes.

+A Taille:
Définit le nombre de threads dans le pool de threads asynchrone, la plage valide est de 0 à 1024. Si fil
l'assistance est disponible, la valeur par défaut est 10.

+B [c | d | i]:
Notre c option fait Ctrl-C interrompre le shell actuel au lieu d'appeler l'émulateur
gestionnaire de pause. Les d option (identique à spécifier +B sans option supplémentaire) désactive
le gestionnaire de pause. Les i L'option fait que l'émulateur ignore tout signal de rupture.

Si la c l'option est utilisée avec vieille coquille sous Unix, Ctrl-C va redémarrer le processus shell
plutôt que de l'interrompre.

Notez que sous Windows, ce drapeau n'est applicable que pour Werl, Pas erl (vieille coquille). Noter
aussi que Ctrl-Pause est utilisé au lieu de Ctrl-C sous Windows.

+c oui | non:
Activer ou désactiver fois de la plateforme prothétique:

oui:
Activer la correction de l'heure. Il s'agit de la valeur par défaut si la correction de l'heure est prise en charge sur le
plate-forme spécifique.

non:
Désactiver la correction de l'heure.

Pour une compatibilité descendante, la valeur booléenne peut être omise. Ceci est interprété comme
+c non.

+C no_time_warp | single_time_warp | multi_time_warp:
Ensemble fois déformer mode:

no_time_warp:
Non Heure Déformer Mode (le défaut)

single_time_warp:
Simple Heure Déformer Mode

multi_time_warp:
Multi Heure Déformer Mode

+d:
Si l'émulateur détecte une erreur interne (ou manque de mémoire), il sera par défaut
générer à la fois un vidage sur incident et un vidage de mémoire. Le vidage de mémoire ne sera cependant pas très
utile car le contenu des tas de processus est détruit par la génération du vidage sur incident.

Notre +d L'option indique à l'émulateur de ne produire qu'un vidage de mémoire et aucun vidage sur incident si
une erreur interne est détectée.

appel erlang:arrêt/1 avec un argument de chaîne produira toujours un vidage sur incident. Sous Unix
systèmes, l'envoi à un processus d'émulation d'un signal SIGUSR1 forcera également un vidage sur incident.

+e Numéro :
Définir le nombre maximum de tables ETS.

+ec:
Forcer le comprimé option sur toutes les tables ETS. Uniquement destiné aux tests et à l'évaluation.

+fnl:
La VM fonctionne avec les noms de fichiers comme s'ils étaient encodés à l'aide de l'encodage ISO-latin-1,
interdisant les caractères Unicode avec des points de code au-delà de 255.

See STDLIB Utilisateurs Guide pour plus d'informations sur les noms de fichiers Unicode. Notez que ce
valeur s'applique également aux paramètres de ligne de commande et aux variables d'environnement (voir STDLIB
Utilisateurs Guide).

+fnu[{w|i|e}]:
La VM fonctionne avec les noms de fichiers comme s'ils étaient encodés en UTF-8 (ou un autre système
codage Unicode spécifique). Il s'agit de la valeur par défaut sur les systèmes d'exploitation qui appliquent
Encodage Unicode, c'est-à-dire Windows et MacOS X.

Notre +fnu l'interrupteur peut être suivi de w, i, ou e pour contrôler la façon dont le fichier encodé à tort
les noms doivent être signalés. w signifie qu'un avertissement est envoyé au enregistreur_erreur chaque fois que
un nom de fichier mal codé est "sauté" dans les listes de répertoires, i signifie que ceux
les noms de fichiers mal codés sont ignorés en silence et e signifie que la fonction API
renvoie une erreur chaque fois qu'un nom de fichier (ou de répertoire) mal codé est rencontré. w
est la valeur par défaut. Noter que fichier:lire_lien/1 renverra toujours une erreur si le lien
pointe vers un nom de fichier invalide.

See STDLIB Utilisateurs Guide pour plus d'informations sur les noms de fichiers Unicode. Notez que ce
valeur s'applique également aux paramètres de ligne de commande et aux variables d'environnement (voir STDLIB
Utilisateurs Guide).

+fna[{w|i|e}]:
Sélection entre +fnl et votre +fnu est fait en fonction des paramètres régionaux actuels dans le
OS, ce qui signifie que si vous avez configuré votre terminal pour l'encodage UTF-8, le système de fichiers est
devrait utiliser le même encodage pour les noms de fichiers. C'est la valeur par défaut sur tous les
systèmes sauf MacOS X et Windows.

Notre +fna l'interrupteur peut être suivi de w, i, ou e. Cela aura un effet si la locale
paramètres provoquent le comportement de +fnu à sélectionner. Voir la description de +fnu au dessus.
Si les paramètres régionaux provoquent le comportement de +fnl à sélectionner, puis w, i, ou e sera
pas d'effet.

See STDLIB Utilisateurs Guide pour plus d'informations sur les noms de fichiers Unicode. Notez que ce
valeur s'applique également aux paramètres de ligne de commande et aux variables d'environnement (voir STDLIB
Utilisateurs Guide).

+hm Taille:
Définit la taille de tas par défaut des processus à la taille Taille.

+hmbs Taille:
Définit la taille de tas virtuel binaire par défaut des processus à la taille Taille.

+hpds Taille:
Définit la taille initiale du dictionnaire de processus des processus à la taille Taille.

+K oui | non:
Active ou désactive la fonctionnalité d'interrogation du noyau si l'émulateur la prend en charge. Défaut
is non (désactivée). Si l'émulateur ne prend pas en charge l'interrogation du noyau et que le +K le drapeau est
transmis à l'émulateur, un avertissement est émis au démarrage.

+l:
Active le traçage automatique du chargement, affichant des informations lors du chargement du code.

+L:
Ne chargez pas d'informations sur les noms de fichiers source et les numéros de ligne. Cela permettra d'économiser certains
mémoire, mais les exceptions ne contiendront pas d'informations sur les noms de fichiers et la ligne
chiffres.

+MFlag Valeur:
Indicateurs spécifiques à l'allocateur de mémoire, voir erts_alloc(3erl) pour plus d'informations.

+n Comportement:
Contrôler le comportement des signaux vers les ports.

À partir de l'OTP-R16, les signaux vers les ports sont réellement délivrés de manière asynchrone. Notez que les signaux
ont toujours été documentés comme asynchrones. L'implémentation sous-jacente a,
cependant, auparavant, ces signaux étaient délivrés de manière synchrone. Erlang correctement écrit
les programmes devraient être capables de gérer cela sans aucun problème. Bugs dans Erlang existant
les programmes qui font de fausses hypothèses sur les signaux vers les ports peuvent, cependant, être difficiles à
trouve. Ce commutateur a été introduit afin au moins de faciliter la comparaison
comportements pendant une période de transition. Noter que ceci. drapeau is obsolète à compter de sa
introduction, et sa suppression est prévue dans OTP-R17. Comportement devrait être l'un des
caractères suivants :

d:
Le défaut. Signaux asynchrones. Un processus qui envoie un signal à un port peut
continuer l'exécution avant que le signal n'ait été délivré au port.

s:
Signaux synchrones. Un processus qui envoie un signal à un port ne continuera pas
l'exécution jusqu'à ce que le signal soit délivré. Devrait uniquement être utilisé pour tester et
débogage.

a:
Signaux asynchrones. Par défaut, mais un processus qui envoie un signal sera même
continuer plus fréquemment l'exécution avant que le signal n'ait été délivré au port.
Si uniquement être utilisé pour les tests et le débogage.

+ ordinateur Catégorie:
Définit la plage de caractères que le système considérera comme imprimables en heuristique
détection de chaînes. Cela affecte généralement le shell, le débogueur et io:format
fonctions (lorsque ~tp est utilisé dans la chaîne de format).

Actuellement, deux valeurs pour le Catégorie sont pris en charge:

latin1:
Le défaut. Seuls les caractères de la plage ISO-latin-1 peuvent être considérés comme imprimables,
ce qui signifie qu'un caractère avec un point de code > 255 ne sera jamais pris en compte
imprimable et que les listes contenant de tels caractères seront affichées sous forme de listes de
des entiers plutôt que des chaînes de texte par des outils.

unicode:
Tous les caractères Unicode imprimables sont pris en compte pour déterminer si une liste de
entiers doit être affiché dans la syntaxe de chaîne. Cela peut donner des résultats inattendus si
par exemple, votre police ne couvre pas tous les caractères Unicode.

Voir aussi io:plage_imprimable/0.

+P Nombre|héritage:
Définit le nombre maximum de processus existants simultanément pour ce système si un
Numéro est passé comme valeur. Plage valide pour Numéro is [1024-134217727]

REMARQUE: Le maximum réel choisi peut être beaucoup plus grand que le Numéro passé. Actuellement
le système d'exécution choisit souvent, mais pas toujours, une valeur qui est une puissance de 2. Cela
pourrait toutefois être modifié à l'avenir. La valeur réelle choisie peut être vérifiée par
appel erlang:info_système(limite_processus).

La valeur par défaut est 262144

If héritage est passé en tant que valeur, l'algorithme hérité pour l'allocation du processus
des identifiants seront utilisés. En utilisant l'algorithme hérité, les identifiants seront attribués dans
un mode strictement croissant jusqu'à ce que le plus grand identifiant possible soit atteint. Noter
que cet algorithme souffre de problèmes de performances et peut sous certaines
circonstances être extrêmement coûteux. L'algorithme hérité est obsolète et le
héritage L'option est prévue pour être supprimée dans OTP-R18.

+Q Nombre|héritage:
Définit le nombre maximum de ports existants simultanément pour ce système si un nombre
est passé comme valeur. Plage valide pour Numéro is [1024-134217727]

REMARQUE: Le maximum réel choisi peut être beaucoup plus grand que le réel Numéro passé.
Actuellement, le système d'exécution choisit souvent, mais pas toujours, une valeur qui est une puissance de
2. Cela pourrait toutefois être modifié à l'avenir. La valeur réelle choisie peut être
vérifié en appelant erlang:system_info(port_limit).

La valeur par défaut utilisée est normalement 65536. Cependant, si le système d'exécution est capable de
déterminer la quantité maximale de descripteurs de fichiers qu'il est autorisé à ouvrir et cette valeur
est plus grand que 65536, la valeur choisie sera augmentée à une valeur supérieure ou égale à
le nombre maximum de descripteurs de fichiers pouvant être ouverts.

Sous Windows, la valeur par défaut est définie sur 8196 parce que les limitations normales du système d'exploitation sont définies
supérieur à ce que la plupart des machines peuvent gérer.

Auparavant, la variable d'environnement ERL_MAX_PORTS a été utilisé pour régler le maximum
nombre de ports existants simultanément. Cette variable d'environnement est obsolète et
prévu pour être supprimé dans OTP-R17, mais peut toujours être utilisé.

If héritage est passé comme valeur, l'algorithme hérité pour l'allocation des identifiants de port
sera utilisé. En utilisant l'algorithme hérité, les identifiants seront attribués de manière strictement
mode croissante jusqu'à ce que l'identifiant le plus grand possible soit atteint. Notez que ce
l'algorithme souffre de problèmes de performances et peut dans certaines circonstances être
extrêmement coûteux. L'algorithme hérité est obsolète et le héritage option est
dont le retrait est prévu dans OTP-R18.

+R Numéro de version:
Définit le mode de compatibilité.

Le mécanisme de distribution n'est pas rétrocompatible par défaut. Ce drapeau définit le
émulateur en mode de compatibilité avec une version antérieure d'Erlang/OTP Numéro de versionL’
le numéro de version doit être dans la plage <actuel version>-2.. sortie>. Ce
limite l'émulateur, lui permettant de communiquer avec les nœuds Erlang (comme
ainsi que les nœuds C et Java) exécutant cette version antérieure.

Remarque : assurez-vous que tous les nœuds (nœuds Erlang, C et Java) d'un système Erlang distribué
est de la même version Erlang/OTP, ou de deux versions Erlang/OTP différentes X et Y,
où tous Les nœuds Y ont le mode de compatibilité X.

+r:
Force ets à déplacer le bloc mémoire sur realloc.

+rg LimiteGroupesLecteur:
Limite le nombre de groupes de lecteurs utilisés par les verrous en lecture/écriture optimisés pour la lecture
opérations dans le système d'exécution Erlang. Par défaut, la limite des groupes de lecteurs est de 64.

Lorsque le nombre d'ordonnanceurs est inférieur ou égal à la limite des groupes de lecteurs, chaque
scheduler a son propre groupe de lecteurs. Lorsque le nombre d'ordonnanceurs est supérieur au
limite des groupes de lecteurs, les planificateurs partagent des groupes de lecteurs. Les groupes de lecteurs partagés se dégradent
les performances de lecture verrouillée et de lecture déverrouillée alors qu'un grand nombre de groupes de lecteurs se dégrade
performances de verrouillage en écriture, la limite est donc un compromis entre les performances de lecture
opérations et performances pour les opérations d'écriture. Chaque groupe de lecteurs consomme actuellement
64 octets dans chaque verrou en lecture/écriture. Notez également qu'un système d'exécution utilisant un lecteur partagé
les groupes bénéficient de propriétés de liant planificateurs à logique processeurs, puisque les groupes de lecteurs
sont mieux répartis entre les ordonnanceurs.

+S Planificateurs : SchedulerOnline:
Définit le nombre de threads du planificateur à créer et les threads du planificateur à mettre en ligne
lorsque la prise en charge SMP a été activée. Le maximum pour les deux valeurs est 1024. Si l'Erlang
le système d'exécution est capable de déterminer le nombre de processeurs logiques configurés et
processeurs logiques disponibles, Planificateurs utilisera par défaut les processeurs logiques
configuré, et PlanificateursEn ligne utilisera par défaut les processeurs logiques disponibles ;
sinon, les valeurs par défaut seront 1. Planificateurs peut être omis si :Planificateur en ligne
n'est pas et vice versa. Le nombre de planificateurs en ligne peut être modifié au moment de l'exécution via
erlang:system_flag(schedulers_online, Planificateurs en ligne).

If Planificateurs or PlanificateursEn ligne est spécifié comme un nombre négatif, la valeur est
soustrait du nombre par défaut de processeurs logiques configurés ou logiques
processeurs disponibles, respectivement.

Spécification de la valeur 0 pour Planificateurs or PlanificateursEn ligne réinitialise le nombre de
threads du planificateur ou threads du planificateur en ligne respectivement à sa valeur par défaut.

Cette option est ignorée si l'émulateur n'a pas activé le support SMP (voir le -smp
drapeau).

+SP PlanificateursPourcentage:PlanificateursOnlinePourcentage:
Similaire à +S mais utilise des pourcentages pour définir le nombre de threads du planificateur à créer,
en fonction des processeurs logiques configurés et des threads du planificateur à définir en ligne, en fonction de
processeurs logiques disponibles, lorsque la prise en charge SMP a été activée. Les valeurs spécifiées doivent
être supérieur à 0. Par exemple, +SP 50:25 définit le nombre de threads du planificateur à 50 %
des processeurs logiques configurés et le nombre de threads planificateurs en ligne à 25%
des processeurs logiques disponibles. PlanificateursPourcentage peut être omis si
 : SchedulersOnlinePourcentage n'est pas et vice versa. Le nombre de planificateurs en ligne peut
être modifié au moment de l'exécution via erlang:system_flag(schedulers_online, Planificateurs en ligne).

Cette option interagit avec +S Les paramètres. Par exemple, sur un système avec 8 cœurs logiques
configurés et 8 cœurs logiques disponibles, la combinaison des options +S 4:4 +SP
50:25 (dans l'un ou l'autre ordre) donne 2 threads du planificateur (50 % sur 4) et 1 planificateur
fil en ligne (25 % sur 4).

Cette option est ignorée si l'émulateur n'a pas activé le support SMP (voir le -smp
drapeau).

+SDcpu DirtyCPUSchedulers:DirtyCPUSchedulersEn ligne:
Définit le nombre de threads de programmation de CPU sales à créer et le programmateur de CPU sale
threads à définir en ligne lorsque la prise en charge des threads a été activée. Le maximum pour les deux
valeurs est de 1024, et chaque valeur est encore limitée par les paramètres de normal
planificateurs : le nombre de threads de planificateur CPU sales créés ne peut pas dépasser le nombre
de threads du planificateur normaux créés et le nombre de threads du planificateur CPU sales
en ligne ne peut pas dépasser le nombre de threads du planificateur normal en ligne (voir le +S et votre +SP
drapeaux pour plus de détails). Par défaut, le nombre de threads de programmation CPU sales créés
est égal au nombre de threads du planificateur normaux créés et au nombre de CPU sales
threads du planificateur en ligne est égal au nombre de threads du planificateur normaux en ligne.
Planificateurs DirtyCPU peut être omis si :DirtyCPUPlanificateurs en ligne n'est pas et vice versa.
Le nombre de programmateurs CPU sales en ligne peut être modifié au moment de l'exécution via
erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).

Cette option est ignorée si l'émulateur n'a pas activé la prise en charge des threads.
À l’heure actuelle, ceci. option is expérimental et n'est pris en charge que si l'émulateur a été
configuré et construit avec la prise en charge des programmateurs sales activés (il est désactivé par
défaut).

+SDPcpu DirtyCPUSchedulersPourcentage:DirtyCPUSchedulersOnlinePourcentage:
Similaire à +SDcpu mais utilise des pourcentages pour définir le nombre de programmateurs CPU sales
threads à créer et nombre de threads de programmation CPU sales à définir en ligne lorsque
la prise en charge des threads a été activée. Les valeurs spécifiées doivent être supérieures à 0. Pour
Par exemple, +SDPcpu 50:25 définit le nombre de threads du programmateur CPU sales à 50 % du
processeurs logiques configurés et le nombre de threads de programmation de CPU sales en ligne pour
25% des processeurs logiques disponibles. DirtyCPUSchedulersPourcentage peut être omis
if :DirtyCPUSchedulersOnlinePourcentage n'est pas et vice versa. Le nombre de CPU sales
les planificateurs en ligne peuvent être modifiés au moment de l'exécution via
erlang:system_flag(dirty_cpu_schedulers_online, DirtyCPUSchedulersOnline).

Cette option interagit avec +SDcpu Les paramètres. Par exemple, sur un système avec 8
cœurs configurés et 8 cœurs logiques disponibles, la combinaison des options +SDcpu
4:4 +SDPcpu 50:25 (dans l'un ou l'autre ordre) aboutit à 2 threads de programmation CPU sales (50 % de
4) et 1 thread de programmation CPU sale en ligne (25 % sur 4).

Cette option est ignorée si l'émulateur n'a pas activé la prise en charge des threads.
À l’heure actuelle, ceci. option is expérimental et n'est pris en charge que si l'émulateur a été
configuré et construit avec la prise en charge des programmateurs sales activés (il est désactivé par
défaut).

+SDio Planificateurs IOS:
Définit le nombre de threads du planificateur d'E/S modifiés à créer lorsque la prise en charge des threads a
été activé. La plage valide est 0-1024. Par défaut, le nombre d'ordonnanceurs d'E/S modifiés
threads créés est de 10, identique au nombre par défaut de threads dans le async fil pool
.

Cette option est ignorée si l'émulateur n'a pas activé la prise en charge des threads.
À l’heure actuelle, ceci. option is expérimental et n'est pris en charge que si l'émulateur a été
configuré et construit avec la prise en charge des programmateurs sales activés (il est désactivé par
défaut).

+sDrapeau Valeur:
Planification de drapeaux spécifiques.

+sbt Type de liaison:
Définissez le type de liaison du planificateur.

Les planificateurs peuvent également être liés à l'aide du +stbt drapeau. La seule différence entre ces
deux drapeaux est la façon dont les erreurs suivantes sont gérées :

* La liaison des planificateurs n'est pas prise en charge sur la plate-forme spécifique.

* Aucune topologie CPU disponible. C'est-à-dire que le système d'exécution n'a pas pu
détecté automatiquement la topologie du processeur, et aucun utilisateur défini Processeur topologie a été mis en.

Si l'une de ces erreurs se produit lorsque +sbt a été passé, le système d'exécution
imprimer un message d'erreur et refuser de démarrer. Si l'une de ces erreurs se produit lorsque +stbt
a été passé, le système d'exécution ignorera silencieusement l'erreur et démarrera
en utilisant des ordonnanceurs non liés.

Actuellement valide Type de liaisons:

u:
non lié - Les planificateurs ne seront pas liés aux processeurs logiques, c'est-à-dire les
le système décide où les threads du planificateur s'exécutent et quand les migrer. Cette
est la valeur par défaut.

ns:
pas de propagation - Les planificateurs avec des identifiants de planificateur proches seront liés aussi près que
possible en matériel.

ts:
fil_spread - Thread fait référence aux threads matériels (par exemple les hyper-threads d'Intel).
Les planificateurs avec des identifiants de planificateur faibles seront liés au premier matériel
thread de chaque cœur, alors les planificateurs avec des identifiants de planificateur plus élevés seront
lié au deuxième thread matériel de chaque cœur, etc.

ps:
processeur_spread - Les planificateurs seront répartis comme fil_spread, mais aussi sur
puces de processeur physique.

s:
propagation - Les programmateurs seront répartis au maximum.

nnts:
no_node_thread_spread - Comme fil_spread, mais si plusieurs NUMA (Non-Uniform
Memory Access) existe, les planificateurs seront répartis sur un nœud NUMA à un
temps, c'est-à-dire que tous les processeurs logiques d'un nœud NUMA seront liés aux ordonnanceurs dans
séquence.

nps:
no_node_processor_spread - Comme processeur_spread, mais si plusieurs nœuds NUMA
existe, les planificateurs seront répartis sur un nœud NUMA à la fois, c'est-à-dire que tous les
les processeurs d'un nœud NUMA seront liés aux ordonnanceurs en séquence.

tnps:
thread_no_node_processor_spread - Une combinaison de fil_spread et
no_node_processor_spread. Les planificateurs seront répartis sur les threads matériels à travers
nœuds NUMA, mais les planificateurs ne seront répartis sur les processeurs en interne que dans un
nœud NUMA à la fois.

db:
liaison_par défaut - Lie les planificateurs de la manière par défaut. Actuellement, la valeur par défaut est
thread_no_node_processor_spread (ce qui pourrait changer à l'avenir).

La liaison des planificateurs n'est actuellement prise en charge que sur les nouveaux Linux, Solaris, FreeBSD,
et les systèmes Windows.

Si aucune topologie CPU n'est disponible lorsque le +sbt le drapeau est traité et Type de liaison est tout
autre type que u, le système d'exécution ne démarrera pas. La topologie du processeur peut être
défini à l'aide de la +sct drapeau. Notez que le +sct le drapeau devra peut-être être passé avant
le +sbt indicateur sur la ligne de commande (au cas où aucune topologie CPU n'a été automatiquement
détectée).

Le système d'exécution sera par défaut pas lier les planificateurs aux processeurs logiques.

NOTE: Si le système d'exécution Erlang est le seul processus du système d'exploitation qui lie
threads aux processeurs logiques, cela améliore les performances du système d'exécution.
Cependant, si d'autres processus du système d'exploitation (comme par exemple un autre runtime Erlang
système) lient également les threads aux processeurs logiques, il peut y avoir un problème de performance
pénalité à la place. Dans certains cas, cette pénalité de performance peut être sévère. Si c'est
le cas, il est conseillé de ne pas lier les planificateurs.

La manière dont les planificateurs sont liés est importante. Par exemple, dans les situations où il y a moins
en cours d'exécution que les planificateurs en ligne, le système d'exécution essaie de migrer
des processus aux planificateurs avec des identifiants de planificateur faibles. Plus les planificateurs sont
répartis sur le matériel, plus le système d'exécution disposera de ressources
dans de telles situations.

NOTE: Si un planificateur ne parvient pas à se lier, cela sera souvent ignoré en silence. Ceci depuis
il n'est pas toujours possible de vérifier des identifiants de processeur logique valides. Si une erreur
est signalé, il sera signalé au enregistreur_erreur. Si vous voulez vérifier que le
les planificateurs ont effectivement lié comme demandé, appelez
erlang:system_info(scheduler_bindings).

+sbt aucun|très_court|court|moyen|long|très_long:
Définir le seuil d'attente occupé du planificateur. La valeur par défaut est moyenne. Le seuil détermine comment
les planificateurs longs doivent attendre lorsqu'ils sont à court de travail avant de s'endormir.

NOTE: Ce drapeau peut être supprimé ou modifié à tout moment sans préavis.

+cl vrai|faux:
Activer ou désactiver le compactage de la charge du planificateur. Par défaut, le compactage du planificateur de
la charge est activée. Lorsqu'il est activé, l'équilibrage de charge s'efforcera d'obtenir une répartition de la charge
ce qui provoque le chargement complet d'autant de threads du planificateur que possible (c'est-à-dire qu'ils ne s'exécutent pas
sans emploi). Ceci est accompli en migrant la charge (par exemple, les processus exécutables) dans
un plus petit ensemble de planificateurs lorsque les planificateurs sont fréquemment à court de travail. Lorsque
désactivé, la fréquence à laquelle les planificateurs manquent de travail ne sera pas prise en compte
compte par la logique d'équilibrage de charge.
+cl non est similaire à +sous oui avec la différence que +sous oui sera également
équilibrer l'utilisation du planificateur entre les planificateurs.

+sct CpuTopologie:

* = entier(); quand 0 =< =< 65535

* = -

* = |

* = , |

* = L

* = T | t

* = C | c

* = P | p

* = N | m

* = |


* CpuTopologie = : |

Définissez une topologie de CPU définie par l'utilisateur. La topologie CPU définie par l'utilisateur écrasera tout
topologie CPU détectée automatiquement. La topologie CPU est utilisée lorsque propriétés de liant
planificateurs à logique processeurs.

Les lettres majuscules signifient de vrais identifiants et les lettres minuscules signifient faux
identifiants utilisés uniquement pour la description de la topologie. Identifiants passés comme réels
les identifiants peuvent être utilisés par le système d'exécution lorsqu'il essaie d'accéder à des
matériel et s'ils ne sont pas corrects, le comportement n'est pas défini. CPU logique falsifié
les identifiants ne sont pas acceptés car il ne sert à rien de définir la topologie CPU
sans véritables identifiants de CPU logiques. Identificateurs de thread, de cœur, de processeur et de nœud
peut être laissé de côté. S'il est omis, l'ID de thread est par défaut t0, l'ID de base est par défaut c0,
l'ID du processeur est par défaut p0, et l'identifiant du nœud ne sera pas défini. Soit chaque logique
le processeur doit appartenir à un et un seul nœud NUMA, ou aucun processeur logique ne doit
appartiennent à n'importe quel nœud NUMA.

A la fois croissant et décroissant s sont autorisés.

Les identifiants de nœud NUMA sont valables à l'échelle du système. C'est-à-dire que chaque nœud NUMA du système doit
avoir un identifiant unique. Les identifiants de processeur sont également à l'échelle du système. Coeur
les identifiants sont à l'échelle du processeur. Les identifiants de thread sont à l'échelle du noyau.

L'ordre des types d'identifiants implique la hiérarchie de la topologie CPU. Valide
les commandes sont soit , ou
. C'est-à-dire que le fil fait partie de
un noyau qui fait partie d'un processeur qui fait partie d'un nœud NUMA, ou thread fait partie
d'un cœur qui fait partie d'un nœud NUMA qui fait partie d'un processeur. Une topologie de processeur
peut être constitué à la fois de nœuds NUMA externes au processeur et internes tant que
chaque processeur logique appartient à un et un seul nœud NUMA. Si is
omis, sa position par défaut sera avant . C'est-à-dire que la valeur par défaut est
nœuds NUMA externes du processeur.

Si une liste d'identifiants est utilisée dans un :

* doit être une liste d'identifiants.

* Au moins un autre type d'identifiant en dehors de il faut aussi avoir un
liste d'identifiants.

* Toutes les listes d'identifiants doivent produire le même nombre d'identifiants.

Un exemple simple. Un seul processeur quadricœur peut être décrit de la manière suivante :

%erl +sct L0-3c0-3
1> erlang:system_info(cpu_topology).
[{processeur,[{core,{logique,0}},
{noyau,{logique,1}},
{noyau,{logique,2}},
{noyau,{logique,3}}]}]

Un exemple un peu plus compliqué. Deux processeurs quad core. Chaque processeur dans son
propre nœud NUMA. L'ordre des processeurs logiques est un peu étrange. Ceci dans l'ordre
pour donner un meilleur exemple de listes d'identifiants :

% erl +sct L0-1,3-2c0-3p0N0:L7,4,6-5c0-3p1N1
1> erlang:system_info(cpu_topology).
[{nœud,[{processeur,[{core,{logique,0}},
{noyau,{logique,1}},
{noyau,{logique,3}},
{noyau,{logique,2}}]}]},
{nœud,[{processeur,[{core,{logique,7}},
{noyau,{logique,4}},
{noyau,{logique,6}},
{noyau,{logique,5}}]}]}]

Tant que les identificateurs réels sont corrects, il est acceptable de transmettre une topologie CPU qui est
pas une description correcte de la topologie du CPU. Lorsqu'il est utilisé avec précaution, il peut en fait
être très utile. Ceci afin de tromper l'émulateur pour lier ses planificateurs lorsque vous
vouloir. Par exemple, si vous souhaitez exécuter plusieurs systèmes d'exécution Erlang sur le même
machine, vous voulez réduire la quantité de planificateurs utilisés et manipuler le CPU
topologie afin qu'ils se lient à différents processeurs logiques. Un exemple, avec deux Erlang
systèmes d'exécution sur une machine quadricœur :

% erl +sct L0-3c0-3 +sbt db +S3:2 -détaché -noinput -noshell -sname one
% erl +sct L3-0c0-3 +sbt db +S3:2 -détaché -noinput -noshell -sname deux

Dans cet exemple, chaque système d'exécution a deux planificateurs chacun en ligne, et tous
les planificateurs en ligne fonctionneront sur différents cœurs. Si nous passons à un seul programmateur en ligne
sur un système d'exécution et trois planificateurs en ligne sur l'autre, tous les planificateurs
online fonctionnera toujours sur des cœurs différents.

Notez qu'une fausse topologie de CPU qui ne reflète pas à quoi ressemble la vraie topologie de CPU
like est susceptible de diminuer les performances du système d'exécution.

Pour plus d'informations, voir erlang:system_info(cpu_topologie).

+ sec vrai|faux:
Activez ou désactivez la planification des E/S à vérification rapide. La valeur par défaut est actuellement ouiL’
la valeur par défaut a été modifiée de non à oui à partir de la version 7.0 d'erts. Le comportement avant
ce drapeau a été introduit correspond à + sec non.

L'indicateur a un effet lorsque les planificateurs vérifieront les opérations d'E/S qu'il est possible d'exécuter,
et quand ces opérations d'E/S seront exécutées. Comme le nom du paramètre l'indique,
les planificateurs seront plus désireux de vérifier les E/S lorsque oui est passé. Ceci cependant
implique également que l'exécution de l'opération d'E/S en attente ne sera pas prioritaire pour
dans la même mesure que lorsque non est passé.

erlang:system_info(eager_check_io) renvoie la valeur de ce paramètre utilisé lorsque
démarrage de la VM.

+wifi intervalle:
Définir l'intervalle de réveil forcé du planificateur. Toutes les files d'attente d'exécution seront analysées chacune intervalle
millisecondes. Tant qu'il y a des planificateurs en veille dans le système, un planificateur
être réveillé pour chaque file d'attente d'exécution non vide trouvée. Un intervalle de zéro désactive cela
fonctionnalité, qui est également la valeur par défaut.

Cette fonctionnalité a été introduite comme solution de contournement temporaire pour les applications natives à exécution longue
code et code natif qui n'effectue pas correctement les réductions dans OTP. Quand ces bogues
ont été fixés le +wifi le drapeau sera supprimé.

+stbt Type de liaison:
Essayez de définir le type de liaison du planificateur. Le même que +sbt drapeau à l'exception de la façon dont
certaines erreurs sont traitées. Pour plus d'informations, consultez la documentation du +sbt
drapeau.

+sous vrai|faux:
Activer ou désactiver ordonnanceur utilisation équilibrage de charge. Par le programmateur par défaut
l'équilibrage de l'utilisation est désactivé et à la place, le compactage de la charge par le planificateur est
activé qui s'efforcera d'obtenir une répartition de la charge qui provoque autant d'ordonnanceurs
threads que possible pour être complètement chargé (c'est-à-dire ne pas manquer de travail). Quand le planificateur
l'équilibrage de l'utilisation est activé, le système essaiera à la place d'équilibrer le planificateur
utilisation entre les planificateurs. C'est-à-dire, s'efforcer d'obtenir une utilisation égale du planificateur sur
tous les programmateurs.
+sous oui n'est pris en charge que sur les systèmes où le système d'exécution détecte et utilise un
horloge haute résolution à augmentation monotone. Sur d'autres systèmes, le système d'exécution
ne pourra pas démarrer.
+sous oui implique +cl non. La différence entre +sous oui et votre +cl non is
qui +cl non n'essaiera pas d'équilibrer l'utilisation du planificateur.

+swct très_désireux|désireux|moyen|paresseux|très_paresseux:
Définir le seuil de nettoyage de réveil du planificateur. La valeur par défaut est moyenne. Ce drapeau contrôle comment
les planificateurs impatients devraient demander le réveil en raison de certaines opérations de nettoyage.
Lorsqu'un paramètre paresseux est utilisé, des opérations de nettoyage plus importantes peuvent être annulées
pendant qu'un planificateur est inactif. Lorsqu'un paramètre dynamique est utilisé, les planificateurs seront plus
être fréquemment réveillé, ce qui augmente potentiellement l'utilisation du processeur.

NOTE: Ce drapeau peut être supprimé ou modifié à tout moment sans préavis.

+sws défaut|héritage:
Définir la stratégie de réveil du planificateur. Stratégie par défaut modifiée dans erts-5.10/OTP-R16A. Cette
stratégie était auparavant connue sous le nom de proposition dans OTP-R15. Les héritage la stratégie a été utilisée
par défaut de R13 jusqu'à et y compris R15.

NOTE: Ce drapeau peut être supprimé ou modifié à tout moment sans préavis.

+swt très_faible|faible|moyen|élevé|très_élevé:
Définir le seuil de réveil du planificateur. La valeur par défaut est moyenne. Le seuil détermine quand
réveillez les planificateurs de sommeil lorsque plus de travail que peut être géré par actuellement éveillé
les ordonnanceurs existent. Un seuil bas provoquera des réveils plus précoces, et un seuil haut
provoquera des réveils ultérieurs. Les premiers réveils répartiront le travail sur plusieurs
les planificateurs plus rapidement, mais le travail rebondira plus facilement entre les planificateurs.

NOTE: Ce drapeau peut être supprimé ou modifié à tout moment sans préavis.

+spp Bool:
Définissez l'astuce du planificateur par défaut pour le parallélisme des ports. Si réglé sur oui, la VM va
planifier les tâches de port en le faisant améliorera le parallélisme dans le système. Si réglé sur
non, la machine virtuelle essaiera d'effectuer les tâches de port immédiatement, améliorant ainsi la latence au
frais de parallélisme. Si cet indicateur n'a pas été passé, l'astuce du planificateur par défaut
pour le parallélisme des ports est actuellement non. La valeur par défaut utilisée peut être inspectée dans
runtime en appelant erlang:system_info(port_parallelism). La valeur par défaut peut être
remplacé lors de la création du port en passant le le parallélisme Option de port_ouvert/2.

+sss Taille:
Taille de pile suggérée, en kilomots, pour les threads du planificateur. La plage valide est 4-8192
kilomots. La taille de pile par défaut dépend du système d'exploitation.

+t Taille:
Définissez le nombre maximal d'atomes que la VM peut gérer. La valeur par défaut est 1048576.

+T Niveau:
Active la synchronisation modifiée et définit le niveau de synchronisation modifié. La plage actuellement valide est
0-9. La synchronisation du système d'exécution changera. Un niveau élevé signifie généralement un
plus grand changement qu'un niveau bas. Changer le timing peut être très utile pour trouver
bugs liés au timing.

Actuellement, le timing modifié affecte les éléments suivants :

Processus frai :
Un processus appelant frayer, spawn_link, spawn_monitor, ou spawn_opt sera programmé
immédiatement après avoir terminé l'appel. Lorsque des niveaux de synchronisation modifiés supérieurs sont
utilisé, l'appelant dormira également pendant un certain temps après avoir été programmé.

Contexte réductions :
Le nombre de réductions qu'un processus est autorisé à utiliser avant d'être programmé est
augmenté ou réduit.

Entrée réductions :
Le nombre de réductions effectuées avant la vérification des E/S est augmenté ou réduit.

NOTE: Les performances en souffriront lorsque la synchronisation modifiée sera activée. Ce drapeau est uniquement
destiné aux tests et au débogage. Notez également que retourner à et votre revenir de tracer
les messages seront perdus lors du traçage sur les BIF de spawn. Ce drapeau peut être supprimé ou
modifié à tout moment sans préavis.

+V:
Oblige l'émulateur à imprimer son numéro de version.

+v:
Verbeux.

+W w | i | e:
Définit le mappage des messages d'avertissement pour enregistreur_erreur. Messages envoyés à l'erreur
l'enregistreur utilisant l'une des routines d'avertissement peut être mappé soit sur des erreurs (+W e),
mises en garde (+W w), ou des rapports d'information (+W i). La valeur par défaut est les avertissements. La cartographie actuelle
peut être récupéré en utilisant error_logger:warning_map/0. Voir enregistreur_erreur(3erl) Pour de plus amples
</br>L’Information.

+zDrapeau Valeur:
Drapeaux divers.

+zdbbl Taille:
Définir la limite d'occupation du tampon de distribution (dist_buf_busy_limit) en kilo-octets. Valide
la plage est 1-2097151. La valeur par défaut est 1024.

Une limite de mémoire tampon plus élevée permettra aux processus de mettre en mémoire tampon plus de messages sortants sur le
Distribution. Lorsque la limite de tampon est atteinte, les processus d'envoi seront
suspendu jusqu'à ce que la taille de la mémoire tampon ait diminué. La limite de tampon est par distribution
canaliser. Une limite plus élevée donnera une latence plus faible et un débit plus élevé au détriment
d'une utilisation plus élevée de la mémoire.

+zdntgc fois:
Définir l'heure de récupération de place de la table des nœuds retardée (delay_node_table_gc) dans
secondes. Les valeurs valides sont soit infini ou un entier dans la plage [0-100000000].
La valeur par défaut est 60.

Les entrées de la table des nœuds qui ne sont pas référencées resteront dans la table pendant au moins la
durée déterminée par ce paramètre. La persistance empêche répété
suppressions et insertions dans les tableaux.

ENVIRONNEMENT VARIABLES

ERL_CRASH_DUMP:
Si l'émulateur doit écrire un vidage sur incident, la valeur de cette variable sera la
nom de fichier du fichier de vidage sur incident. Si la variable n'est pas définie, le nom du crash
le fichier de vidage sera erl_crash.dump dans le répertoire courant.

ERL_CRASH_DUMP_NICE:
Unix les systèmes: si l'émulateur a besoin d'écrire un vidage sur incident, il utilisera la valeur de
cette variable pour définir la bonne valeur pour le processus, abaissant ainsi sa priorité. Les
la plage autorisée est de 1 à 39 (les valeurs les plus élevées seront remplacées par 39). Le plus haut
La valeur 39 donnera au processus la priorité la plus basse.

ERL_CRASH_DUMP_SECONDS:
Unix les systèmes: Cette variable donne le nombre de secondes que l'émulateur sera
autorisé à passer à écrire un vidage sur incident. Lorsque le nombre de secondes indiqué s'est écoulé,
l'émulateur sera terminé par un signal SIGALRM.

Si la variable d'environnement est pas réglé ou il est réglé sur zéro seconde,
ERL_CRASH_DUMP_SECONDS=0, le système d'exécution n'essaiera même pas d'écrire le crash
fichier de vidage. Il va juste se terminer.

Si la variable d'environnement est définie sur une valeur négative, par exemple ERL_CRASH_DUMP_SECONDS=-1,
le système d'exécution attendra indéfiniment que le fichier de vidage sur incident soit écrit.

Cette variable d'environnement est utilisée en conjonction avec Cœur if Cœur est en cours d'exécution:

ERL_CRASH_DUMP_SECONDS=0:
Supprime entièrement l'écriture d'un fichier de vidage sur incident, redémarrant ainsi le système d'exécution
immédiatement. Cela revient à ne pas définir la variable d'environnement.

ERL_CRASH_DUMP_SECONDS=-1:
La définition de la variable d'environnement sur une valeur négative entraînera l'arrêt de
le système d'exécution à attendre que le fichier de vidage sur incident soit complètement écrit.

ERL_CRASH_DUMP_SECONDS=S:
attendra S secondes pour terminer le fichier de vidage sur incident, puis terminer le
système d'exécution.

ERL_AFLAGS:
Le contenu de cette variable d'environnement sera ajouté au début de la commande
ligne pour erl.

Notre -supplémentaire drapeau est traité spécialement. Sa portée se termine à la fin de l'environnement
contenu variable. Arguments à la suite d'un -supplémentaire drapeau sont déplacés sur la ligne de commande
into the -supplémentaire section, c'est-à-dire la fin de la ligne de commande qui suit après un -supplémentaire
drapeau.

ERL_ZFLAGS et votre ERL_FLAGS:
Le contenu de ces variables d'environnement sera ajouté à la fin de la commande
ligne pour erl.

Notre -supplémentaire drapeau est traité spécialement. Sa portée se termine à la fin de l'environnement
contenu variable. Arguments à la suite d'un -supplémentaire drapeau sont déplacés sur la ligne de commande
into the -supplémentaire section, c'est-à-dire la fin de la ligne de commande qui suit après un -supplémentaire
drapeau.

ERL_LIBS:
Cette variable d'environnement contient une liste de répertoires de bibliothèque supplémentaires que le
Le serveur de code recherchera les applications et les ajoutera au chemin du code. Voir code(3erl).

ERL_EPMD_ADDRESS:
Cette variable d'environnement peut être définie sur une liste d'adresses IP séparées par des virgules, dans
quel cas le epmd démon n'écoutera que sur la ou les adresses spécifiées et sur le
adresse de bouclage (qui est implicitement ajoutée à la liste si elle n'a pas été spécifiée).

ERL_EPMD_PORT:
Cette variable d'environnement peut contenir le numéro de port à utiliser lors de la communication avec
epmd. Le port par défaut fonctionnera correctement dans la plupart des cas. Un port différent peut être spécifié
pour permettre aux nœuds de clusters indépendants de coexister sur le même hôte. Tous les nœuds d'un
cluster doit utiliser le même numéro de port epmd.

CONFIGURATION

Le système Erlang/OTP standard peut être reconfiguré pour modifier le comportement par défaut sur
Commencez.

Notre .erlang Démarrage Fichier:
Au démarrage d'Erlang/OTP, le système recherche un fichier nommé .erlang dans le
répertoire où Erlang/OTP est démarré. S'il n'est pas trouvé, le répertoire personnel de l'utilisateur est
recherché un fichier .erlang.

Si un fichier .erlang est trouvé, il est supposé contenir des expressions Erlang valides. Ces
les expressions sont évaluées comme si elles étaient entrées dans le shell.

Un fichier .erlang typique contient un ensemble de chemins de recherche, par exemple :

io:format("exécution du profil utilisateur dans HOME/.erlang\n",[]).
code:add_path("/home/calvin/test/ebin").
code:add_path("/home/hobbes/bigappl-1.2/ebin").
io:format(".erlang rc terminé\n",[]).

utilisateur_par défaut et votre shell_default :
Les fonctions du shell qui ne sont pas préfixées par un nom de module sont supposées être
objets fonctionnels (Funs), fonctions intégrées (BIF), ou appartiennent au module
user_default ou shell_default.

Pour inclure des commandes shell privées, définissez-les dans un module user_default et ajoutez le
argument suivant comme première ligne dans le fichier .erlang.

code:load_abs("..../user_default").

erl :
Si le contenu de .erlang est modifié et qu'une version privée de user_default est
défini, il est possible de personnaliser l'environnement Erlang/OTP. Des changements plus puissants
peut être fait en fournissant des arguments de ligne de commande dans le script de démarrage erl. Faire référence à
erlde Géographie (1) et avec la init(3erl) pour plus d'informations.

Utiliser erl en ligne à l'aide des services onworks.net