Mise en mémoire tampon indésirable lors du filtrage de la sortie de la console dans Win32

Question

Ma question concerne "Turn off buffering in pipe", mais concerne Windows plutôt que Unix. J'écris un make clone et pour arrêter les processus parallèles de thrashing la sortie de la console des autres j'ai redirigé la sortie vers les tuyaux (comme décrit dans here) sur lequel je peux faire le filtrage que je veux. Malheureusement, les processus de longue durée mettent maintenant leur production en tampon plutôt que de l'envoyer en temps réel comme ils le feraient sur une console. De la lecture des sources MSVCRT, il semble que la cause première soit que GetFileType() soit utilisé pour vérifier si les handles d'E/S standard sont attachés à une console, qui définit ensuite un indicateur interne et finit par désactiver la mise en mémoire tampon.

Apparemment, un tableau séparé de poignées et d'indicateurs de fichiers héritables peut également être transmis via le membre lpReserved2 non documenté de la structure STARTUPINFO lors de la création du processus. A propos de la seule solution de travail que j'ai compris est d'utiliser cette liste et de mentir sur le type de périphérique lors de la définition des indicateurs pour stdout/stderr.

Maintenant alors ... Y a-t-il une solution à ce problème? sane?

Answer 1

Il n'y en a pas. Oui, GetFileType() indique que stdout n'est plus un périphérique char, _isatty() renvoie false alors le CRT bascule le flux de sortie en mode buffer. Important pour obtenir un débit raisonnable. Le rinçage d'un caractère à la fois n'est acceptable que lorsqu'un humain les regarde.

Vous devrez rééditer les programmes que vous essayez de rediriger avec une version personnalisée du CRT. Je ne doute pas que si cela était possible, vous ne seriez pas en train de jouer avec cela en premier lieu. Corriger GetFileType() est une autre solution non-sane.