Re: OT: xterm Was: Re: MIME-type-Auswertung ohne Gnome/KDE

From: Lars Engels <lars.engels(at)0x20.net>
Date: Thu, 30 Aug 2012 18:44:42 +0200

On Thu, Aug 30, 2012 at 02:24:32PM +0200, Oliver Fromme wrote:
> Polytropon <freebsd(at)edvax.de> wrote:
> > On Wed, 29 Aug 2012 21:31:07 +0200, Christoph Sold wrote:
> > > Leider warten die Programme, bis xterm mit dem Scrollen fertig ist.
> > > Leitet man alle Ausgaben nach /dev/null um, werden die meisten
> > > Programme ungemein schnell.
> >
> > Ist das so? Ich dachte, die Ausgabe wäre _gepuffert_,
> > so daß man mit einem > /dev/null keinen Geschwindigkeits-
> > unterschied erzielt... oder verwechsle ich da was?
>
> Bei >/dev/null leitet es die Shell direkt nach /dev/null,
> und das Terminal bekommt die Ausgaben nie zu Gesicht.
> Das geht ziemlich fix.
>
> Ohne Umleitung gehen die Ausgaben über ein Pseudo-TTY an
> den Terminal-Prozess (in diesem Fall xterm). Hier kann
> an drei Stellen gepuffert werden: Bei der Ausgabe des
> laufenden Programmes (cat o.ä.), im TTY-Code des Kernels,
> und evtl. im Eingangscode des Terminal-Prozesses (xterm).
>
> Den TTY-Buffer im Kernel kann man vergessen; der ist nicht
> groß. Der Ausgabepuffer des Programms in der Regel auch
> nicht: Wenn mit setvbuf() nichts anderes festgelegt wird,
> ist stderr immer ungepuffert, und stdout ist lediglich
> zeilengepuffert, wenn es mit einem TTY verbunden ist.
>
> Da jedes xterm ein einzelner single-threaded Prozess ist,
> kann er keine Eingangsdaten annehmen, wenn er gerade mit
> etwas anderem beschäftigt ist, z.B. mit dem Rendern des
> Fensterinhalts. Und wenn er keine Daten annimmt, dann
> blockiert der sendende Prozess (z.B. cat), sobald die
> Puffer voll sind -- was recht schnell geschieht, da sie
> ja eher klein bzw. gar nicht vorhanden sind (siehe oben).

Genau, und bei richtig großen Dateien kann man wie ein Wilder auf Ctrl+C
herumhacken und xterm scrollt schön weiter...


To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 30 Aug 2012 - 18:44:47 CEST

search this site