Cette commande est utilisée pour créer des file event handlers Un gestionnaire d'évènement de fichier est une liaison entre un canal et un script, Ainsi le script est évalué chaque fois que le canal devient lisible ou inscriptible. Les gestionnaires d'évènement de fichier sont plus couramment utilisés pour autoriser les données à être reçues d'un autre processus sur une base pilotée par évènement, permettant au récepteur de continuer à interagir avec l'utilisateur en attendant que les données arrivent. Si une application appelle gets ou read sur un canal bloquant quand il n'y a pas de données entrantes disponibles, le processus bloquera; jusqu'a ce que les données entrantes arrivent, il ne sera pas capable de prendre en charge d'autres évènements, donc il apparaitra à l'utilisateur "gelé" Avec fileevent, le processus peut savoir quand les données sont présentes et appeller seulement gets ou read quand elles ne bloqueront pas.

L'argument channelId à fileevent se refère à un canal ouvert, tel que la valeur de retour d'une précédente commande open ou socket. Si l'argument script est spécifié, alors fileevent crée un nouveau gestionnaire d'évènement script qui sera évalué chaque fois que le canal devient lisible ou inscriptible (dépendant du second argument de fileevent). Dans ce cas fileevent retourne une chaîne vide. Les gestionnaires d'évènements readable et writable sont indépendants, et peuvent être créés et effacés séparément. Néanmoins, il peut y avoir au plus un gestionnaire readable et writable pour un fichier à un instant donné dans un interpréteur donné. Si fileevent est appelé quand le gestionnaire spécifié existe déjà dans l'interpréteur d'appel, le nouveau script remplace l'ancien.

Si l'argument script n'est pas spécifié, fileevent retourne le script courant de channelId, ou une chaîne vide s'il n'y en a aucun. Si l'argument script est spécifié comme chaîne vide alors le gestionnaire d'évènement est effacé, ainsi aucun script ne sera appelé. Un gestionnaire d'évènement de fichier est aussi effacé automatiquement chaque fois que son canal est fermé ou son interpréteur effacé.

Un canal est consideré lisible si il y a des données non lues disponibles sur le périphérique sous-jacent. Un canal est aussi consideré lisible si il y a des données non lues dans un tampon d'entrée, excepté dans le cas spécial où la plus récente tentative de lire à partir du canal comme un appel à gets qui n'a pas pu trouver une ligne complète dans le tampon d'entrée. Cette fonctionnalité permet à un fichier d'être lu une ligne à la fois en mode non bloquant en utilisant les évènements. Un canal est aussi consideré lisible si une fin de fichier ou une condition d'erreur est présente sur le fichier ou le périphérique sous-jacent. Il est important pour le script de vérifier ces conditions et de les gérer opportunément par exemple, s'il n'y a pas de verification spéciale pour la fin du fichier, une boucle infinie peut se produire si le script ne lit pas de données, retourne, et est immédiatement appelé de nouveau.

Un canal est consideré inscriptible si au moins un octet de données peut être écrit sur le fichier ou périphérique sous-jacent sans bloquer, ou si une condition d'erreur est présente sur le fichier ou périphérique sous-jacent.

Les I/O pilotées par évènements fonctionnent mieux avec les canaux placés en mode non bloquant avec la commande fconfigure. En mode bloquant, une commande puts peut bloquer si vous lui donnez plus de données que le fichier ou périphérique sous-jacent peut accepter, et une commande gets ou read bloquera si vous tentez de lire plus de données que prètes aucun événement ne sera traité pendant que les commandes bloquent. En mode non bloquant puts, read, et gets ne bloquent jamais. Voir la documentation de ces commandes individuelles pour plus d'informations sur comment elles gèrent les canaux bloquants et non bloquants.

Le script pour un évènement fichier est exécuté au niveau global (en dehors du contexte de quelconque fonction Tcl) dans l'interpréteur dans lequel la commande fileevent a été appelée. Si une erreur se produit pendant l'exécution du script alors le mécanisme bgerror est utilisé pour rapporter l'erreur. De plus, le gestionnaire d'évènement fichier est effacé si jamais il retourne une erreur, c'est fait de manière à empêcher les boucles infinies dues aux gestionnaires bogués

fileevent Commandes Internes Tcl