Brevet FR3025627A1 — publié le 20160311

MECANISME HAUTE PERFORMANCE POUR GENERATION D'INFORMATIONS DE JOURNALISATION D'UN PROCESSUS INFORMATIQUE DOMAINE DE L'INVENTION L'invention concerne le domaine de la journalisation de processus au sein d'une application logicielle exécutée sur un ensemble de dispositifs de traitement de l'information. Plus particulièrement, l'invention concerne un procédé permettant la journalisation de processus dans le cas d'une application logicielle fonctionnant avec plusieurs processus et/ou fils d' exécution. CONTEXTE DE L'INVENTION La journalisation ou « logging » en langue anglaise est un mécanisme permettant d'exporter des informations en cours d'exécution d'une application logicielle destinée au développeur, au testeur, ou à d'autres personnes d'une équipe technique ayant en charge l'application logicielle. Ces informations permettent de révéler certains dysfonctionnements, ou, ceux-ci connus, d'en faciliter la détermination de la cause et la correction. L'exportation des informations de journalisation peut se faire pendant des phases de développement de l'application logicielle, ou en phase de tests au sein d'une communauté de testeurs, mais également en phase de production. Les informations de journalisation sont alors exportées chez les utilisateurs de l'application, mais peuvent être « remontées » d'une façon ou d'une autre à l'équipe technique en charge du logiciel. Les informations de journalisation peuvent être exportées vers un terminal de visualisation, ou vers une mémoire, notamment une mémoire de masse de type « disque dur ». 3025627 2 Certains applications logicielles « critiques » nécessitent des temps de réponse fortement contraints mais requièrent une grande quantité de calculs. Pour concilier ces deux exigences, elles sont classiquement déployées sur 5 des systèmes composés d'un ensemble de dispositifs de traitement de l'information. Il est alors fait appel à des techniques de programmation parallèle afin de tirer profit de ces dispositifs de traitement. Toutefois, malgré ce parallélisme qui peut être massif, concilier le temps de réponse et le traitement d'une très grande quantité de calculs reste 10 une contrainte forte. Or, la journalisation nécessite des entrées/sorties, vers un terminal de visualisation ou une mémoire, par exemples. Les mécanismes d'entrée/sorties sont coûteux en termes de temps de traitement. Par conséquent, la journalisation impacte les performances d'une application 15 logicielle. Dans le cadre d'une application logicielle critique, il est même très souvent choisi de ne pas effectuer de journalisation afin de ne pas diminuer ses performances. Il en résulte alors une difficulté pour révéler et corriger les dysfonctionnements de cette application logicielle. 20 RESUME DE L'INVENTION Le but de la présente invention est d'améliorer l'état de la technique en fournissant des mécanismes pour permettre une journalisation efficace, y 25 compris pour des applications logicielles critiques, notamment des applications logicielles parallèles. A cette fin, la présente invention propose un procédé de journalisation comportant des étapes consistant à : 3025627 3 Exécuter un processus comportant au moins un fil applicatif et au moins un fil de journalisation sur un ensemble de dispositifs de traitement de l'information ; Détecter au sein du au moins un fil applicatif un événement de 5 journalisation et transmettre immédiatement des premières informations de journalisation audit au moins un fil de journalisation; Recevoir lesdites premières informations de journalisation et élaborer des secondes informations de journalisation à partir 10 desdites premières informations de journalisation; et, Publier lesdites secondes informations de journalisation à travers une interface de publication vers au moins un élément de traitement inscrit auprès dudit au moins un fil de journalisation. 15 Suivant des modes de réalisation préférés, l'invention comprend une ou plusieurs des caractéristiques suivantes qui peuvent être utilisées séparément ou en combinaison partielle entre elles ou en combinaison totale entre elles : 20 ledit au moins un élément de traitement comprend un fil de sortie appartenant audit processus. ledit au moins un élément de traitement comprend un fil d'un processus de journalisation distinct dudit processus. ledit fil applicatif transmet lesdites premières informations 25 audit au moins un fil de journalisation de façon asynchrone à travers une interface de communication. ladite interface de communication et ladite interface de publication sont de type socket et conformes à la bibliothèque ZeroMQ. 30 au démarrage dudit processus, ledit au moins un fil applicatif attend l'initialisation dudit au moins un fils de journalisation 3025627 4 avant de poursuivre son exécution, et dans lequel ledit fils de journalisation s'initialise en se synchronisant avec un sous-ensemble dudit au moins un élément de traitement. lesdites premières informations de journalisation comprennent 5 un nom et un niveau. lorsque ledit processus est dupliqué, ledit au moins un fil de journalisation est terminée, puis redémarrée au sein du processus parent initial. lorsque ledit au moins un fils de journalisation reçoit un signal, 10 il publie des secondes informations de journalisation liées audit signal, puis déclenche le code de traitement associé audit signal. lorsque ledit fils applicatif reçoit un signal, il transmet des premières informations de journalisation liées audit signal 15 audit au moins un fil de journalisation, attend durant un temps déterminé puis provoque la terminaison dudit processus. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit d'un mode de réalisation préféré de 20 l'invention, donnée à titre d'exemple et en référence aux dessins annexés. BREVE DESCRIPTION DES DESSINS La figure 1 représente schématiquement un exemple de mise en oeuvre 25 de l'invention. La figure 2 représente schématiquement une machine à états finis selon un mode de réalisation de l'invention. 30 3025627 5 DESCRIPTION DETAILLEE DE L'INVENTION D'une façon logicielle, une application logicielle est constituée d'un ou plusieurs processus. 5 Un processus, ou « process » en langue anglaise, peut être vu comme un programme en cours d'exécution par un système de traitement de l'information (ou ordinateur). Un processus peut être défini comme comportant : Un ensemble d'instructions à exécuter, pouvant être dans la mémoire 10 morte, mais le plus souvent chargé depuis la mémoire de masse vers la mémoire vive ; un espace d'adressage en mémoire vive pour stocker la pile, les données de travail, etc. ; Des ressources telles que les ports réseau. 15 Un même processus peut comporter plusieurs fils d'exécution ou, « threads » en langue anglaise, ou encore tâche ou processus léger. A la différence d'un processus, un fil d'exécution ne dispose pas de sa propre mémoire virtuelle mais la partage avec tous les fils d'un même processus. 20 Dans l'exemple illustré par la figure 1, une application comporte deux processus Pi, P2. Le processus Pi comporte trois fils d'exécution F1, F2, F3. Quoi que cela ne soit pas représenté sur la figure, le processus P2 peut également comporter plusieurs fils d'exécution. Il est à noter que les fils d'exécution peuvent avoir une durée de vie 25 différente de celle des processus, et, a fortiori, de la durée d'exécution de l'application : les fils peuvent être exécutés dynamiquement en cours d'exécution du processus et terminés à tout moment, une fois la tâche pour laquelle ils sont prévus achevée. La figure 1 illustre donc une situation à un moment donné de l'exécution de l'application logicielle. 3025627 6 Dans la suite, les fils d'exécution F1, F2 seront appelés « fils applicatif », afin de les distinguer du ou des fils de journalisation et du fil de sortie FS qui seront décrit plus loin. 5 Le système de traitement de l'information permettant d'exécuter l'application logicielle est typiquement un système parallèle formé d'ensemble de dispositifs de traitement de l'information. Chaque dispositif de traitement de l'information peut être par exemple un microprocesseur avec des circuits associés (mémoire...), et le système 10 est alors formé d'un ensemble de microprocesseurs interconnectés. Un autre exemple est celui d'un microprocesseur unique formant un système, et composé d'un ensemble de coeurs physiques. Un tel microprocesseur est généralement appelé multi-coeurs (ou « multicore » en langue anglaise). Quelque soit l'architecture mise en oeuvre, les processus Pi, P2, Pj de 15 l'exemple de la figure 1 et les fils d'exécution qu'ils comportent peuvent être exécutés en parallèle. Lorsque le processus P1 démarre au moins un fil d'exécution démarre également. Ce premier fil peut par la suite lancer l'exécution d'autres fils. 20 Ces fils peuvent bien évidemment être des fils applicatifs (c'est-à-dire appartenant à l'application et permettant de mettre en oeuvre la « logique » de l'application), mais aussi notamment des fils de journalisation F. Dans la suite, ainsi qu'illustré sur la figure 1, un seul fil de journalisation est décrit. Il est toutefois possible de prévoir plusieurs fils de 25 journalisation, notamment afin de permettre une répartition de charge. Selon un mode de réalisation, lorsque le fil de journalisation démarre il créé : Une interface de communication Tc, permettant la réception de 30 premières informations de journalisation des fils applicatifs F1, F2, 3025627 7 c'est-à-dire du fil applicatif principal et d'éventuels fils qu'il pourra ensuite créer ; Une interface de publication Ip permettant de publier des secondes informations de journalisation vers des éléments de traitement 5 On appelle ici « éléments de traitement » les fils d'exécution et les processus. Sur la figure 1, comme nous le verrons ultérieurement, le processus de journalisation Pj et le fil de sortie Fs forme de tels éléments de traitement qui sont susceptibles de recevoir les informations de journalisation. 10 Selon un mode de réalisation de l'invention, ces interfaces sont de type « socket ». Un « socket » est un mécanisme de communication bien connu de l'homme du métier, apparu sur les systèmes d'exploitation de type « Unix » mais aujourd'hui présent sous la plupart des systèmes 15 d'exploitation. Elles peuvent par exemple être conformes à ZeroMQ. ZeroMQ est une plateforme de type « middleware » qui s'insère entre le système d'exploitation sous-jacent et les applications afin d'apporter des services d'infrastructure supplémentaires et indépendants du système d'exploitation. 20 Par rapport à des plateformes concurrentes telles CORBA, par exemple (Common Object Request Broker Architecture), ZeroMQ apporte une grande facilité d'utilisation et de très bonnes performances : le code est très court pour les fils application, engendrant peu de surcharge de traitement, et le traitement au sein-même de la bibliothèque ZeroMQ est également très 25 rapide. De sorte, ZeroMQ répond aux exigences de l'invention et permet de remplir les services souhaités sans ajout d'un traitement préjudiciable. Les mécanismes offerts par ZeroMQ sont notamment accessibles à travers une bibliothèque à du code applicatif en langage C. Les mécanismes et avantages de l'invention sont donc accessibles pour des processus 30 développés en langage C. 3025627 8 Selon un mode de réalisation, l'interface de communication Tc est une interface asynchrone : elle permet au fil applicatif d'émettre des informations de journalisation, puis de poursuivre son traitement, sans avoir à attendre un acquittement de la part du fil de journalisation F. 5 Dans le cadre d'une mise en oeuvre utilisant ZeroMQ, cette interface de communication Tc peut être de type push/pull. Auquel cas, dès son démarrage, le fil de journalisation créé un socket de type « pull ». Les fils applicatifs Fi, F2 peuvent alors transmettre les informations de journalisation à travers un socket de type « push » connectée au socket 10 « pull » du fil de journalisation F. Entre les deux types de sockets formant l'interface de communication Tc un protocole de transport inter-fil et intraprocessus comme le protocole « inproc » peut être mis en place. Ce protocole permet la transmission de messages entre fils à l'intérieur d'un même processus : l'information est 15 transmise directement par la mémoire appartenant au contexte associé au processus. Ce mécanisme n'engendre donc pas d'entrées/sorties, et contribue donc aux hautes performances du procédé selon l'invention. L'interface de publication Ip peut comprendre un socket de type « pub » créé au sein du fil de journalisation F. Les éléments de traitement 20 (processus ou fils) Pj, Fs peuvent créer des sockets de type « sub » afin de s'abonner (« subscribe » en anglais) au socket « pub » du fil de journalisation Pj. Le modèle « publish-subscribe » géré par ZeroMQ permet ainsi de transmettre des messages vers tous les éléments de traitement préalablement abonnés. 25 Selon un mode de réalisation de l'invention, au démarrage du processus Pi, le fil applicatif attend l'initialisation de ce fils de journalisation Fj avant de poursuivre son exécution. Lorsqu'il lance l'exécution du fil de journalisation Fj, le fil (principal) 30 du processus Pi peut préciser un nombre d'éléments de traitement qui doivent recevoir des informations de journalisation. 11 recevra un 3025627 9 acquittement de la part du fil de journalisation Fj que lorsque ce nombre d'éléments de traitement abonné sera atteint. Une fois l'acquittement reçu, le fil d'exécution peut alors poursuivre son exécution. 5 De même, le fil de journalisation Fj s'initialise en se synchronisant avec le nombre d'éléments de traitement qui doivent recevoir des informations de journalisation. Pour ce faire, le fil de journalisation Fj peut publier des informations de synchronisation. A leur réception, les éléments de traitement qui les ont 10 reçus vont transmettre un acquittement au fil de journalisation. Celui-ci peut compter les acquittements reçus et aisément déterminer lorsque le nombre spécifié est atteint. Cette phase de synchronisation permet de s'assurer qu'aucune information de journalisation n'est perdue : en effet, l'établissement de la 15 connexion entre le fil de journalisation Fj et les éléments de traitement peut prendre un certain temps. En outre, les éléments de traitement eux-mêmes peuvent être en cours d'initialisation également. Durant ce temps, si le fil de journalisation Fj commençait immédiatement à émettre des informations de journalisation, celles-ci seraient perdues, du fait de l'absence d'acquittement 20 dans la transmission des informations de journalisation publiées de la part des éléments de traitement récepteurs. Cette absence d'acquittement permet d'atteindre des bonnes performances Or, dans certaines situations, il peut être important voire crucial de ne perdre aucune information de journalisation. 25 Selon cette mise en oeuvre, il est donc possible de spécifier le nombre des éléments de traitement pour lesquels la réception de l'ensemble des informations de synchronisation doit être garantie par ce mécanisme de synchronisation. Ce nombre d'éléments détermine un sous ensemble de l'ensemble des 30 éléments de traitements abonnés, car une fois la phase d'initialisation terminée, il est tout à fait possible que d'autres éléments de traitement 3025627 10 s'abonnent aux publications du fil de journalisation F. Toutefois, ceux-ci peuvent manquer les premières publications du fil de journalisation F. Le procédé de journalisation selon l'invention comporte une étape 5 d'exécution du processus Pi. Comme précédemment décrit, cette exécution implique l'exécution d'au moins un fil applicatif F1 et d'un fil de journalisation F. Dans le cas d'un processus écrit en langage C, ce fil applicatif F1 peut correspondre à l'exécution de la fonction main(). Une fois la phase d'initialisation terminée, le ou les fils applicatifs 10 exécutent le code de l'application logicielle. Le procédé consiste alors à détecter au sein du ou des fils applicatifs un événement de journalisation et à transmettre immédiatement des premières informations de journalisation el, e2 au fil de journalisation F. La détection d'un événement de journalisation est une technique 15 connue en soi, qui consiste à insérer des jalons (ou « logger ») dans le code afin de déclencher un événement de journalisation lorsque certaines conditions sont remplies. Ces conditions peuvent être tout simplement le passage par un point précis du code (afin de permettre de suivre le déroulement du code), ou bien une situation d'erreur, etc. 20 Ces informations de journalisation générées par le fil applicatif F1, F2 sont ici appelées « premières informations de journalisation » afin de les distinguer des secondes informations de journalisation qui seront celles publiées par le fil de journalisation F. Ces informations peuvent ne comporter qu'un nom et un niveau. 25 Selon un mode de réalisation, ces premières informations ne comportent que ce nom et ce niveau. Le nom peut être une chaîne de caractères identifiant un jalon au sein du code applicatif. Le niveau est généralement un nombre entier, identifiant un degré de 30 criticité de l'événement. Ce niveau peut appartenir à une liste préalablement définie qui peut comprendre : 3025627 11 « Critical » : pour indiquer une erreur critique qui, en général, engendre la terminaison du processus. « Error » : pour indiquer une erreur normale « Warning » : pour indiquer une erreur peu importante 5 « Output » : pour indiquer un message normal, non lié à une erreur. « Info » : pour indiquer un message destiné à l'utilisateur de l'application (et non pas uniquement au développeur ou testeur) « Debug » : pour indiquer un message davantage de détail, destiné à des testeurs (ou « débogueurs ») de l'application 10 « Trace » : pour indiquer un message lié au niveau le plus détaillé. Son utilisation est sans doute destinée au stade de développement de l' application. Cette liste est évidement non exhaustive. Bien d'autres niveaux peuvent être définis par le développeur de l'application. 15 Il est important que toutes les sorties destinées aux développeurs ou testeurs soient conformes à ce formalisme afin d'être prises en compte par les mécanismes de l'invention. Il est notamment donc important pour le développeur d'éviter des sorties directes, notamment par la fonction printf() du langage C : elles peuvent être remplacées par le niveau « Output » par 20 exemple. Ces premières informations peuvent également comprendre : une date (« timestamp ») de survenue de l'événement de journalisation ; 25 un identifiant du processus Pi, d'autres informations sur le contexte d'exécution : identifiant du fil du noyau (« kernel »), nom de l'application logicielle, nom du fichier, numéro de la ligne du code applicatif, nom de la fonction en cours d'exécution, etc. 30 3025627 12 Selon l'invention, le fil applicatif transmet immédiatement ces premières informations de journalisation au fil de journalisation Fj au travers de l'interface de communication Tc. Comme il a été vu précédemment, cette interface est asynchrone et ne nécessite pas 5 d'acquittement. Aucun verrou n'est non plus mis en place, de sorte qu'une fois l'émission effectuée (et sans se préoccuper de la réception par le fil de journalisation), le fil applicatif F1, F2 peut poursuivre immédiatement le traitement applicatif. Selon un mode de réalisation, aucun autre traitement n'est appliqué 10 entre la détection d'un événement de journalisation et l'émission des premières informations de journalisation. Selon un mode de réalisation, uniquement un traitement de mise au format est appliqué. En aucun cas, selon l'invention, le fil applicatif ne met en place des 15 mécanismes d'entrées/sorties : ces mécanismes sont mis en oeuvre par le fil de journalisation Fj, et donc déportés hors du fil applicatif F1, F2. Il en résulte que pour le fil applicatif, le surcoût est réduit au minimum. 20 Selon un mode de réalisation de l'invention, le code applicatif est divisé en modules. Chaque module est associé à un nom ou identifiant, qui peut être incorporé dans le nom du jalon de journalisation. Par exemple, dans un module « Modulel », des jalons de noms « Modulel alonl », « Modulel.jalon2 », etc. 25 Ce mécanisme permet de nommer de façon plus claire les différents événements de journalisation : en fin de chaîne, on peut ainsi déterminer directement l'emplacement du code où a eu lien l'événement en fonction du nom de module inclut dans son nom. 30 Le fil de journalisation Fj reçoit de façon asynchrone les premières informations de journalisation émises par le ou les fils applicatifs F1, F2 3025627 13 Son rôle est alors d'élaborer des secondes informations de journalisation à partir de des premières informations de journalisation reçues des fils applicatifs, et, éventuellement, d'informations complémentaires. Ces informations complémentaires peuvent être des informations communes 5 à l'ensemble des fils applicatifs du processus. Le traitement mis en oeuvre par le fil de journalisation Fj peut se limiter à l'élaboration de ces secondes informations de journalisation. L'élaboration peut comprendre d'une part l'adjonction des éventuelles 10 informations complémentaire mais aussi une mise en forme, selon un format prédéfini permettant son exploitation par des éléments de traitement. Cette mise au format peut être très simple et uniquement consister en un formatage de sorte que les secondes informations soient dans un 15 format indépendant du langage informatique utilisé. Ces secondes informations sont ensuite publiées par le fil de journalisation Fj à travers l'interface de publication Ip. Elles peuvent alors être reçues par un ou plusieurs éléments de traitement Fs, Pj 20 préalablement inscrits auprès du fil de journalisation, ainsi que précédemment décrit. Ces éléments de traitement peuvent comprendre un fil de sortie FS appartenant au processus Pl. Ce fil de sortie peut être prévu pour 25 réaliser une sortie des secondes informations de journalisation sur un terminal de visualisation (écran...), dans un fichier stocké sur une mémoire, notamment une mémoire de masse, etc. Ces mécanismes de sortie sont en général coûteux en temps de traitement du fait de l'interaction nécessaire avec du matériel et, en 30 général, de la nécessité d'un acquittement (le fil doit s'assurer que l'information a bien été mémorisée sur le disque dur, etc.). 3025627 14 Grace à l'invention, ces mécanismes n'impactent pas le fil applicatif qui suit son déroulement de façon parallèle à celui du fil de journalisation. 5 Les éléments de traitement peuvent également comprendre un processus de journalisation Pj distinct dudit processus Pi. Ce processus peut également mettre en oeuvre des mécanismes de sortie de la même façon qu'un fil de sortie Fs. Il peut aussi mettre en oeuvre des mécanismes plus complexes 10 d'exploitation des informations de journalisation : filtrage, etc. Selon une mise en oeuvre de l'invention, lorsque le processus P1 est dupliqué, le fil de journalisation Fj et l'éventuel fil de sortie Fs sont terminées, puis redémarrées au sein du processus parent initial P1. Au sein 15 du processus fils, ces deux fils ne sont pas redémarrés (ils passent dans un état « finalized », comme il sera décrit plus loin). En effet, très souvent, le processus fils va déclencher l'exécution d'une fonction « exec() » qui va remplacer et « écraser » le contenu du processus fils par un nouveau programme : il est donc inutile de déclencher un redémarrage automatique 20 des fils de journalisation et de sortie, et même contre-productif. La duplication, ou fourche, « fork » en langue anglaise, est le mécanisme de création d'un nouveau processus dans une application logicielle fonctionnant sous un système d'exploitation de type « Unix », ou conforme à la norme Posix. 25 La duplication d'un processus comportant plusieurs fils d'exécution (« multithreaded » selon la terminologie anglaise) pose des problèmes importants. Cette problématique est notamment exposée dans la norme Posix, IEEE 1003.1, notamment dans la partie « Rationales » Le mécanisme mis en oeuvre par l'invention permet de les éviter. 30 3025627 15 En outre, une gestion d'une machine à états peut être mise en place afin de gérer au mieux les duplications « fork() ». La figure 2 illustre une telle machine à états du fil de journalisation F. On considère que le fil Fj peut être dans 5 états principaux. Ces états sont 5 classiques : « Unset » (indéterminé), correspondant à un état « non démarré ». Cela correspondant à l'état dans lequel le fil peut être avant que le fil applicatif ne déclenche son initialisation. « Initializing » (initialisation), correspondant à un état d'initialisation 10 du fil, durant lequel notamment ont lieu l'étape de synchronisation préalablement décrite. « initialized » (initialisé), correspondant au fonctionnement normal du fil de journalisation. « finalizing » (terminaison) correspondant à la terminaison du fil de 15 journalisation « Finalized » (terminé) correspondant à un état où le fil est terminé Dans certains états, selon ce mode de réalisation de l'invention, les duplications sont interdites. C'est le cas des états « initializing » et « finalizing » : le flèche « fork() » aboutit à un état « illégal » 20 Dans les états particuliers « unset » et « finalized », la duplication peut être autorisée et ne pas donner lieu à des traitements particuliers. La flèche « fork() » reboucle sur l'état courant. Dans l'état « initialized », la duplication amène la transition vers l'état « finalizing » afin de terminer le fil de journalisation. 25 Il en va de même pour l'éventuel fil de sortie Fs. Une fois les fils terminés, le processus peut être dupliqué. Une fois la duplication effectuée, les fils Fj et Fs peut être redémarrés. Dans le processus parent (c'est-à-dire le processus initial P1), les fils sont redémarrés dans l'état où ils étaient avant la duplication, c'est-à-dire l'état 30 « Initialized ». Dans le processus fils, les fils démarrent dans un état 3025627 16 « unset » : le fil applicatif du processus fils doit alors lancer son initialisation pour le faire changer d'état. Par ailleurs, un processus P1 fonctionnant sous un système de type 5 Posix ou unix peut recevoir des signaux. Ces signaux peuvent être prévus pour terminer le processus, comme les signaux SIGINT, SIGTERM, SIGQUIT, SIGSEGV, SIGBUS. Lorsqu'un tel signal est reçu par le fil de journalisation Fj, celui-ci 10 peut choisir de les traiter ou non selon leur nature. Par exemple, les signaux SIGINT, SIGTERM et SIGQUIT peuvent être considérés comme devant être traités par le fil applicatif et donc non considérés par le fil de journalisation. Il peut par contre considérer d'autres types de signaux comme les signaux SIGSEGV et SIGBUS. 15 A la réception d'un tel signal, le fil de journalisation Fj peut considérer qu'il s'agit d'un événement de journalisation, et publier alors des informations de journalisation, liées à ce signal. Ensuite, il peut à nouveau déclencher ce signal et son traitement « normal ». Le traitement normal d'un signal est assuré par un code de 20 traitement, appelé typiquement « handler », et associé à ce signal. Le traitement normal de ce signal SIGSEGV ou SIGBUS entraine la terminaison du processus. Ainsi, grâce à ce mécanisme, le processus adopte le comportement 25 attendu consistant à se terminer, mais il est aussi assuré qu'une journalisation a lieu lié à la réception de cet événement : aussi, si un élément de traitement est abonné au fil de journalisation, il sera informé de la cause de la terminaison du processus P1. 30 Si un signal est reçu par le fil applicatif, celui-ci peut déterminer qu'il s'agit d'un événement de journalisation. Pour ce faire, un code spécifique 3025627 17 peut être associé au signal en tant que « handler » : à la réception d'un signal donné, c'est ce code spécifique qui est déclenché par le système d' exploitation. Ce code spécifique permet la transmission immédiate de (premières) 5 informations de journalisation vers le fil de journalisation au travers de l'interface de communication Tc. Ce code peut également prévoir un temps d'attente permettant au fil de journalisation d'élaborer des secondes informations de journalisation à partir de ces premières informations de journalisation et de les publier via 10 l'interface de publication. Seulement alors, le code spécifique peut appeler le code normal de traitement pour réaliser la terminaison du processus ou terminer lui-même le processus. Ainsi, les éléments de traitement abonnés peuvent être informés de la 15 cause de la terminaison du processus. Bien entendu, la présente invention n'est pas limitée aux exemples et au mode de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. 20 REVENDICATIONS1. Procédé de journalisation comportant des étapes consistant à : Exécuter un processus (P1) comportant au moins un fil applicatif (F1, F2) et au moins un fil de journalisation (Fj) sur un ensemble de dispositifs de traitement de l'information ; Détecter au sein du au moins un fil applicatif un événement de journalisation et transmettre immédiatement des premières informations de journalisation audit au moins un fil de journalisation (Fi) ; Recevoir lesdites premières informations de journalisation et élaborer des secondes informations de journalisation à partir desdites premières informations de journalisation; et, Publier lesdites secondes informations de journalisation à travers une interface de publication (Ip) vers au moins un élément de traitement (Fs, Pi) préalablement inscrit auprès dudit au moins un fil de journalisation. 2. Procédé selon la revendication 1, dans lequel ledit au moins un élément de traitement comprend un fil de sortie (FS) appartenant audit processus (Pi). 3. Procédé selon l'une des revendications 1 ou 2, dans lequel ledit au moins un élément de traitement comprend un fil d'un processus de journalisation (Pi) distinct dudit processus (P1). 4. Procédé selon l'une des revendications précédentes dans lequel ledit fil applicatif (F1) transmet lesdites premières informations audit au moins un fil de journalisation de façon asynchrone à travers une interface de communication (Tc). 3025627 19 5. Procédé selon la revendication précédente, dans lequel ladite interface de communication et la dite interface de publication sont de type socket et conformes à la bibliothèque ZeroMQ. 5 6. Procédé selon l'une des revendications précédentes, dans lequel au démarrage dudit processus (P1), ledit au moins un fil applicatif (F1, F2) attend l'initialisation dudit au moins un fils de journalisation (Fj) avant de poursuivre son exécution, et dans lequel ledit fils de journalisation s'initialise en se synchronisant avec un sous-ensemble dudit au moins un 10 élément de traitement (Fs, Pj). 7. Procédé selon l'une des revendications précédentes dans lequel lesdites premières informations de journalisation comprennent un nom et un niveau. 8. Procédé selon l'une des revendications précédentes, dans lequel lorsque ledit processus (P1) est dupliqué, ledit au moins un fil de journalisation (Fj) est terminée, puis redémarrée au sein du processus parent initial (Pi). 9. Procédé selon l'une des revendications précédentes, dans lequel lorsque ledit au moins un fils de journalisation reçoit un signal, il publie des secondes informations de journalisation liées audit signal, puis déclenche le code de traitement associé audit signal. 25 10. Procédé selon l'une des revendications précédentes, dans lequel lorsque ledit fils applicatif reçoit un signal, il transmet des premières informations de journalisation liées audit signal audit au moins un fil de journalisation, attend durant un temps déterminé puis provoque la terminaison dudit processus. 15 20