Effet de Ctrl-S / XOFF sur le processus

Question

Pendant que je courais, apt upgradej'ai accidentellement envoyé un Ctrl- Sà cette fenêtre de terminal.

Maintenant , je connais XOFF, XON, Ctrl- Q, et quelque chose de nouveau au sujet téléscripteur.

Quand j'ai envoyé un Ctrl- Qau terminal "en pause", j'ai aptcontinué son travail.

D'après la lecture XOFF, je ne sais pas ce qui s'est passé aptou ce qui se passe généralement dans toute commande qui reçoit un fichier XOFF. htoparrête de mettre à jour l'affichage, ce qui est bon à savoir, mais est htoptoujours en cours d'exécution?

Courait apttoujours? Ou a été aptet htopeffectivement mis en pause, gelé?

Apparemment, les processus peuvent toujours recevoir des entrées, alors XOFFqu'ils sont toujours en cours d'exécution.

Qu'est-ce qui se passe? Par exemple, le compteur de programmes, apparemment, n'arrête pas simplement d'incrémenter le compteur de programmes, gelant le programme.

Cela dépend-il de la façon dont la commande est programmée pour gérer XOFF? Y a-t-il un comportement général auquel on peut s'attendre avec les commandes Linux de base?

Answer 1

htoparrête de mettre à jour l'affichage, ce qui est bon à savoir, mais est htoptoujours en cours d'exécution [après que Ctrl-S a été entré]?

Oui absolument. htopou toute autre commande n'est PAS arrêtée ou gelée par Ctrl-S.

Le IXONparamètre termios ne fonctionne pas comme ISIG. La saisie des caractères VSTOP(Ctrl-S) ou VSTART(Ctrl-Q) n'envoie AUCUN signal au processus en cours d'exécution dans le terminal.

C'est très facile de vérifier cela; ouvrir deux terminaux: dans la première entrée

tail -f /tmp/file

et dans le second

cat > /tmp/file

Maintenant, dans le deuxième terminal, tapez Ctrl-S, puis continuez à taper aveuglément les lignes suivies de Entrée. Ils apparaîtront à l'écran dans le premier terminal. Si au lieu de catcela, c'est un shell et que ce sont des commandes similaires rm ..., elles seront exécutées sans avoir à être renvoyées à l'écran.

ce qui se passe généralement dans toute commande qui reçoit un XOFF.

La commande ne "reçoit pas de XOFF". Tout est géré dans le pilote du terminal. Du point de vue de l'application, rien ne se passe. Si le programme continue d'envoyer une sortie abondante (ou que le ECHOparamètre termios est activé - par défaut - et qu'il continue de recevoir une entrée abondante), toute écriture (ou lecture respective) sur le terminal se bloquera à un moment donné jusqu'à ce que le Ctrl-Q soit reçu.

Answer 2

Comme vous le savez peut-être déjà, XONet XOFF, liés par défaut à Ctrl+ Set Ctrl+ Q, sont des caractères de contrôle de flux logiciel et en principe des reliques de l' ancien temps des terminaux de télétype d'impression papier . Ils étaient utilisés à des moments où un équipement de réception (souvent une imprimante à papier) ne pouvait parfois pas suivre l'entrée envoyée par un expéditeur distant.

De nos jours, les télétypes papier ne sont plus utilisés, mais l'idée qui les sous-tend est toujours conservée dans le cadre logiciel d'un "terminal" (voir par exemple ici et ce très bel article sur l'histoire du TTY ), qui a hérité et implémente encore une partie des les concepts utilisés dans les terminaux papier d'origine - l'un étant la capacité d'interpréter les caractères de contrôle de flux.

Habituellement, un programme fonctionnant "sur la console", c'est-à-dire connecté à un pseudo-terminal, ne voit pas les caractères XONet XOFFtels qu'ils sont par défaut capturés par le terminal, où le comportement standard XOFFest d'arrêter d'imprimer la sortie. reçoit du programme. Le programme lui-même n'est par ailleurs pas affecté et continue de s'exécuter en arrière-plan, seule la sortie n'est pas "envoyée en avant" à l'utilisateur jusqu'à ce qu'un XONnouveau soit reçu.

Si vous écrivez un programme et que vous souhaitez recevoir explicitement ces caractères d'entrée, vous pouvez utiliser l' tcsetattr()appel système dans votre programme pour désactiver le contrôle de flux logiciel via le IXOFFdrapeau (voir ici, par exemple ) - nanofait cela , par exemple.