YEngine/fr

From OpenSimulator

Revision as of 11:34, 2 December 2020 by Acryline (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

Sommaire

Il s'agit d'une alternative à XEngine, moteur de script pleinement fonctionnelle pour les scripts LSL/OSSL, avec :

  • multitâche préemptif
  • Amélioration de la syntaxe du script
  • Contrôle de l'utilisation de la pile et du paquet de mémoire par script
  • Nouvelles extensions du langage en option

YEngine effectue une traduction directe du langage de script vers le code .net IL, ce qui le rend plus rapide à compiler que XEngine. XEngine traduit le langage de script en C#, puis utilise le compilateur .net pour générer l'IL, ce qui est naturellement plus lent. Alors que XEngine pouvait compiler des scripts dans d'autres langages comme le C#, YEngine ne prend en charge que le LSL. Pour des raisons de sécurité, ces autres langues ne peuvent pas pu être utilisées pour l'instant, sauf dans des cas très particuliers et limités.

Une fois qu'un code de script est chargé sur XEngine, la mémoire utilisée par celui-ci ne peut pas être récupérée lors de la suppression du script, sauf si une fonctionnalité .net appelée AppDomains est utilisée.
Mais les AppDomains sont très lourds, utilisent beaucoup plus de mémoire et, pire encore, ont un impact négatif énorme sur les performances des scripts
Pour les appels traversant des domaines (c'est-à-dire le script et le framework principal), tous les paramètres et les valeurs de retour sont sérialisés et désérialisés par les domaines émetteur et récepteur.

Yengine charge le code des scripts d'une manière différente, la plupart de leur mémoire est récupérée à la suppression sans avoir besoin de ces AppDomains.

Multitâche préemptif

YEngine exécute des événements de script en utilisant le multitâche préemptif.
Cela signifie que, à certains points de contrôle ou lorsqu'on le lui demande, un script peut arrêter son exécution, pour être placé dans une file d'attente et attendre son tour pour s'exécuter à nouveau.
Le fil d'exécution libéré peut ainsi continuer à traiter d'autres scripts.

Lorsqu'un nouvel événement commence son exécution, il est autorisé à se dérouler pendant environ 60 ms (sous réserve de modifications) jusqu'à la libération de l'exécution. Lorsqu'il est à nouveau exécuté, il est autorisé à fonctionner pendant 30 ms supplémentaires (sous réserve de modifications). Cela sera répété jusqu'à ce que tout le code de l'événement soit exécuté
Le moteur donnera une plus grande priorité aux événements courts et rapides.

Le script peut également être placé en état de veille pendant un temps déterminé.
Cela permet par exemple de résoudre l'un des problèmes les plus graves de XEngine : llSleep() et autres attentes internes de script.

Avec YEngine, cette attente ne fait qu'arrêter l'exécution qui va attendre dans une file d'attente, jusqu'à ce que le temps de sommeil soit écoulé.

Avec XEngine, un fil d'exécution "coûteux" est placé en mode "Sleep", donc non disponible pour faire quoi que ce soit.

Amélioration de la syntaxe du script

YEngine suit de plus près la syntaxe du script LSL et l'ordre d'exécution.

Des instructions comme

 if(oneKey)
   ...

devrait maintenant fonctionner.

 llSomething; // missing()
 break; // mais voir les nouvelles extensions

sont désormais des erreurs.

L'ordre d'exécution des déclarations complexes peut être différent de celui de XEngine. Il faut toujours utiliser des parenthèses (...) pour faire exécuter l'ordre souhaité (et dans n'importe quelle langage) !

Nouvelles extensions du langage en option

Ces informations sont relatives à la version Yeti 0.9.2.0 Dev, l'ancienne version n'utilisant que la LSL/OSSL normale.


Contrôle de l'utilisation de la pile et du paquet de mémoire par script

Activation

Configuration

Origines

Personal tools
General
About This Wiki