Exécute un script quand un canal devient lisible ou inscriptible

fileevent channelId readable ?script?
fileevent channelId writable ?script?

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’à ce que les données entrantes arrivent, il ne sera pas capable de prendre en charge d'autres événements, donc il apparaîtra à l'utilisateur “gelé” Avec fileevent, le processus peut savoir quand les données sont présentes et appeler seulement gets ou read quand elles ne bloqueront pas.

L'argument channelId à fileevent se réfè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 considéré lisible si il y a des données non lues disponibles sur le périphérique sous-jacent. Un canal est aussi considéré 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 considéré 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 vérification 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 considéré 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 commandefconfigure. 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 disponible 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