Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?

[Cordess]

Ich muss gestehen, ich nutze sie nie, zumindest nicht explizit selber. Ich nutze zwar pipes, aber keine named pipes. Wenn ich so ein Feature benötige, dann benutze ich meist eine temporäre Datei in einer RAM Disk auf bspw. /dev/shm. Zwar ist das nicht völlig gleichwertig mit einer named pipe, kommt ihr aber sehr ähnlich. Dass irgendwelche Skripte und Programme sie nutzen, kann schon sein, aber das meinte ich mit dieser Frage nicht, es geht um das explizite selber nutzen.

Wie sieht's bei euch aus?

Wer nicht weiß was das ist:
https://en.wikipedia.org/wiki/Named_pipe#In_Unix

In dem Artikel steht auch ein Beispiel drin, was der Vorteil gegenüber einer gewöhnlichen temporären Datei ist.

[Meillo]

Ich nutze sie nur ganz selten. Der typische Anwendungsfall fuer mich ist, wenn ich ein laenger laufendes Programm von aussen fernsteuern will.

[chrbr]

Ich habe sie zwar vor langer Zeit mal ausprobiert, aber noch nie produktiv verwendet. Ich bin allerdings auch kein Profi in Sachen IT.

[am2]

Ich bin ein ex-ITler (privat immer noch aber nicht mehr beruflich) und höre/lese gerade das erste Mal davon. Ob nun vom heutigen Standpunkt betrachtet oder rückblickend - ein Produktiver Einsatz fällt mir auch nicht ein. Ausprobieren schadet allerdings nicht

[tobo]

Ein Fall, wo mkfifo nützlich ist, wäre z.B. als Ersatz für Process Subsitution in dash und mksh.

[Cordess]

Danke für eure Antworten.

[Cordess]

Das FIFO Prinzip scheint bei named pipes nicht konsistent umgesetzt zu werden, zumindest konnte ich das auf meinem Mehrkernersystem nicht beobachten:

Code: Alles auswählen

mkfifo testpipe
echo "0" > testpipe &
echo "1" > testpipe &
echo "2" > testpipe &
echo "3" > testpipe &
echo "4" > testpipe &

Wird dann der auslesnde Befehl, hier cat, in einem anderen Terminal ausgeführt, dann erhält man:

Code: Alles auswählen

cat testpipe
3
2
1
0
4

Wird der cat Befehl im gleichen Terminal ausgeführt, dann ist die Reihenfolge entsprechend dem FIFO Prinzip so wie sie sein sollte. Also 0, 1, 2, 3, 4.

Die genaue Ursache kenne ich nicht, meine erste Vermutung war, dass es an den mehreren Kernen liegen könnte, was dazu führen könnte, dass die einzelnen Prozesse zu einer unterschiedlichen zeitlichen Ausführung kommen könnten.
Gemäß

Code: Alles auswählen

man 3 mkfifo

heißt es darin nämlich auch:

However, it has to be open at both ends simultaneously before you can proceed to do any input or output operations on it. Opening a FIFO for reading normally blocks until some other process opens the same FIFO for writing, and vice versa.

D.h. die ganzen schreibenden "echo" Prozesse können erst in die named Pipe schreiben, wenn diese mit dem lesenden "cat" Prozess auch abgefragt wird. Da könnte es also schon sein, dass die Prozesse auf verschiedene CPU Kerne verteilt werden und die dann unterschiedlich schnell fertig werden.

Die einzelnen Prozesse an einen einzigen bestimmten CPU Kern zu binden hat allerdings auch daran nichts geändert:

Code: Alles auswählen

taskset -c 0 echo "0" > testpipe &
taskset -c 0 echo "1" > testpipe &
taskset -c 0 echo "2" > testpipe &
taskset -c 0 echo "3" > testpipe &
taskset -c 0 echo "4" > testpipe &

Und dann im anderen Terminal:

Code: Alles auswählen

cat testpipe
2
1
3
0
4

Auch den cat Prozess an nur einen CPU Kern zu binden, half auch nichts:

Code: Alles auswählen

taskset -c 0 cat testpipe
4
0
3
2
1

Insofern weiß ich jetzt nicht, woran es noch liegen könnte.
Meine CPU hat noch Hyperthreading, aber daran kann es eigentlich auch nicht liegen, da taskset das meiner Meinung nach berücksichtigt.

[heisenberg]

Na wenn Du alle Prozesse in den Hintergrund schickst, dann sind die alle quasi-gleichzeitig aktiv und wer dran kommt ist in den Feinheiten des Timings des Kernelspaces bzw. des Zufalls verborgen.

Wenn Du das im Vordergrund laufen lässt, dann bleibt die Reihenfolge erhalten:

Terminal 1:

Code: Alles auswählen

mkfifo testpipe
tail -f testpipe

Terminal 2:

Code: Alles auswählen

echo "0" > testpipe
echo "1" > testpipe
echo "2" > testpipe
echo "3" > testpipe
echo "4" > testpipe

Terminal 1 - Fortsetzung:

Code: Alles auswählen

0
1
2
3
4

[tobo]

Wenn Du das im Vordergrund laufen lässt, dann bleibt die Reihenfolge erhalten:

Man kann sie auch erstmal nur zum Schreiben öffnen:
Terminal 1:

Code: Alles auswählen

$ mkfifo pipe
$ exec 3>pipe
echo 0 >&3
echo 1 >&3
echo 2 >&3
echo 3 >&3
echo 4 >&3
exec 3>&-   #Schließt die zum Schreiben geöffnete Pipe. Die Ausgaben danach erfolgen erst (und automatisch), wenn cat ausgeführt wird.
$ echo 0 >&3
$ echo 1 >&3
$ echo 2 >&3
$ echo 3 >&3
$ echo 4 >&3
$ exec 3>&-
$

Terminal 2:

Code: Alles auswählen

$ cat pipe
0
1
2
3
4
$

[heisenberg]

@tobo: Das ist ja das gleiche, was ich tue: Du schreibst sequentiell von einem Programm da rein.

Mir scheint es so, als ob die named Pipe anders als der Name "mkfifo" sagt, nur ein Element speichert und nicht eine Kette von Elementen.

[Cordess]

Na wenn Du alle Prozesse in den Hintergrund schickst, dann sind die alle quasi-gleichzeitig aktiv und wer dran kommt ist in den Feinheiten des Timings des Kernelspaces bzw. des Zufalls verborgen.

Wenn Du das im Vordergrund laufen lässt, dann bleibt die Reihenfolge erhalten:

Was du hier machst ist tail zu benutzen. Versuch das mit cat, dann geht es nicht mehr.
Machst du das mit echo im Vordergrund, dann wartet echo darauf, dass du mit cat den Wert abfragst. Eine weitere Eingabe ist dann nämlich nicht möglich, zumindest nicht im gleichen Terminal, weil der erste echo Befehl noch wartet.
Das bedeutet aber dass du den FIFO nicht mit allen Werten füllen kannst, wenn du cat starten musst, um den ersten echo Befehl zu beenden, so dass du den nächsten eingeben kannst.
Deswegen habe ich alle echo Befehle in den Hintergrund geschickt, damit ich die folge Echo Befehle eingeben kann.

Aber du könntest damit recht haben, dass das die Erklärung dafür sein könnte, warum die Reihenfolge sich ändert.

[tobo]

@tobo: Das ist ja das gleiche, was ich tue: Du schreibst sequentiell von einem Programm da rein.

Mir scheint es so, als ob die named Pipe anders als der Name "mkfifo" sagt, nur ein Element speichert und nicht eine Kette von Elementen.

Das Schreiben hat erst dann Relevanz, wenn die Pipe auch zum Lesen geöffnet wird. Und das machst du mit tail -f direkt, das cat macht das aber erst nach Abschluss.

[GregorS]

Mir scheint es so, als ob die named Pipe anders als der Name "mkfifo" sagt, nur ein Element speichert und nicht eine Kette von Elementen.

Nein, FIFO steht für „first in, first out“ - es können sich also durchaus sehr viele Elemente in der Pipe befinden. Es kommt hinten halt in der Reihenfolge raus, in der es in die Schlange kam - im Ggs. zum „LIFO“-Gebilde (last in, first out, ein „Stapel“).

Ich hatte bislang erst ein mal mit einer named pipe zu tun und das war noch nicht einmal in einem von mir stammenden Script* zu finden.

Gruß

Gregor

*PS: viewtopic.php?p=1340022#p1340022

[tobo]

Mir scheint es so, als ob die named Pipe anders als der Name "mkfifo" sagt, nur ein Element speichert und nicht eine Kette von Elementen.

Nein, FIFO steht für „first in, first out“ - es können sich also durchaus sehr viele Elemente in der Pipe befinden.

Solange die Pipe nicht zum Lesen geöffnet ist, ist die Pipe blockiert. Da befindet sich also weder ein Element, noch viele Elemente - die Pipe ist komplett leer. Und das bleibt sie - egal was man meint, vorne reingeschüttet zu haben - bis sie zum Lesen geöffnet wird, wodurch die Blockade aufgehoben wird.

[Meillo]

Btw: Im Kontext von Unix ist ``Element'' = ``Byte'' und ``Kette von Elementen'' = ``Folge von Bytes''. Das Prinzip ist aber natuerlich das gleiche.

[heisenberg]

Ich habe ja selbst nicht wirklich Ahnung und versuche mir das nur anhand dessen was ich sehe zu erklären.

Eine "Pipe" sehe ich da irgendwie nicht. D. h. ein Element in der Prozesskette, dass beliebige Elemente(Bytes) aufnimmt und dann an den Abnehmer weitergibt. Ich sehe da eher eine "Schnittstelle". Wenn an der Schnittstelle ein "Leser" ist, dann darf der "Schreiber" seine Daten loswerden. Bei den Lesern gibt's verschiedene: 1. So etwas wie "cat", dass nachschaut, ob Daten geliefert werden und dann ggf. liest bis nix mehr da ist oder 2. So etwas wie "tail -f", dass Daten liefert, die da sind und dann weiter wartet, auch wenn nix mehr geliefert wird.

Als Pipe würde ich mir einen Speicher vorstellen, der eine definierte Größe hat, wo man Daten abliefern kann, bis die Pipe voll ist und erst dann der/die Schreibeprozess(e) blockiert wird.

Die Frage ist ob es so etwas wie die von mir gedachte Pipe auch gibt, oder ob es nur die "Schnittstellenvariante" gibt.

[Meillo]

Die Pipe in einer Shell-Pipeline (also letztlich das `|'-Zeichen) ist eine *unnamed* Pipe. Technisch ist sie intern gleich wie eine named Pipe, bloss hat sie eben keinen Namen, d.h. keinen Dateisystemeintrag, sondern wird vom Kernel automatisch angelegt und nach dem Ende der damit verbundenen Prozesse wieder entfernt.

Du hast Recht, dass eine Pipe einen internen Pufferspeicher hat. Wann dabei blockiert wird, ist eine unabhaengige Entscheidung. Es macht Sinn, dass das Schreiben blockiert wird, wenn es keine Leser gibt, damit nicht unnoetig geschrieben und zwischengespeichert wird, fuer den Fall, dass nie Leser kommen. Soweit ich sehe kann man dieses Verhalten aber auch aendern:

Opening a FIFO for
reading normally blocks until some other process opens
the same FIFO for writing, and vice versa. See fifo(7)
for nonblocking handling of FIFO special files.

Am besten, du liest dir mal die Manpage fifo(7) durch, da wird das erklaert.

[heisenberg]

Na, fifo(7) scheint da erst der Anfang.

Da stellt sich mir dann doch eher die Frage: Wird das wirklich so gebraucht? Oder ist es mit dem blockieren nicht ein vernünftiger Default, der einem auch sofort anzeigt, dass was schief ist, wenn etwas blockiert.

Üblicherweise ist es ja eher so, dass Daten sofort bearbeitet werden, also quasi ununterbrochen gelesen werden (also die "tail -f" - Variante). Da stellt sich die Frage nach dem Puffer dann eigentlich nicht, bzw. die Frage in die Runde: Welche Anwendungsfälle gibt es für so etwas?

[tobo]

Da stellt sich mir dann doch eher die Frage: Wird das wirklich so gebraucht? Oder ist es mit dem blockieren nicht ein vernünftiger Default, der einem auch sofort anzeigt, dass was schief ist, wenn etwas blockiert.

Was meinst du damit - werden named pipes gebraucht oder werden blockierende named pipes gebraucht?

Üblicherweise ist es ja eher so, dass Daten sofort bearbeitet werden, also quasi ununterbrochen gelesen werden (also die "tail -f" - Variante). Da stellt sich die Frage nach dem Puffer dann eigentlich nicht, bzw. die Frage in die Runde: Welche Anwendungsfälle gibt es für so etwas?

Für blockierende named pipes? Als Ersatz für Dateien z.B.: Mein Beispiel von oben, die fehlende Process Substitution in mksh und dash:

Code: Alles auswählen

## In Bash:
$ diff <(printf "a\nb\nc\n") <(printf "a\nB\nc\n")
2c2
< b
---
> B
$

## In Dash:
$ mkfifo {f1,f2}
$ printf "a\nb\nc\n" >f1 &
[1] 29458
$ printf "a\nB\nc\n" >f2 &
[2] 29465
$ diff f1 f2
2c2
< b
---
> B
[1]-  Done                    printf "a\nb\nc\n" > f1
[2]+  Done                    printf "a\nB\nc\n" > f2
$ rm {f1,f2}
$

[heisenberg]

Die blockierenden named pipes sind ja da.

Ob die nicht blockierende, die auf Vorrat schon mal Daten speichernde Named-Pipe, obwohl gerade (noch) niemand liest, gebraucht werden, das ist meine Frage.

[Meillo]

Code: Alles auswählen

$ mkfifo {f1,f2}

Das ist ja eine interessante Notation. Gibt es einen bestimmten Grund, warum du hier eine Brace Expansion verwendest, statt `mkfifo f1 f2' zu schreiben?

[tobo]

Das simple hintereinanderreihen ist mir gedanklich jetzt gar nicht gekommen, sonst hätte ich es gemacht. Siehe `rm {f1,f2}'!?

[wanne]

Die pipe macht exakt was du willst. Das Problem ist, dass du nicht verstehst, was dein Script macht. Nur weil ein Befehl weiter oben in deinem Script steht, wird er nicht zuerst ausgeführt. Bitte mache das Beispiel, In dem du einfach 5 Konsolen aufmachst und nacheinander die Befehle ausführst.


Mit & werden deine Prozesse nebenläufig ausgeführt.
Nebenläufig heißt unter Linux üblicherweise: Der Kernel entscheidet sich alle 0.7ms* für ein paar↓ mehr oder minder zufällige Prozesse, die dann 4ms laufen dürfen. Und das ist dann halt mal der Prozess aus Zeile 5 vor dem aus Zeile 2 ausgeführt wird. Deine pipe zeigt dir wunderbar korrekt an, in welcher Reihenfolge die echos ausgeführt wurden. Nur deine Bash führt sie in anderer Reihenfolge aus, als du das vermutest. In C oder Python wäre dir das vermutlich nicht passiert.


Jetzt gibt es noch 3 Sonderfälle:
* Du hast Hyperthreading und deswegen startet der Linux-Kernal 2 Prozesse auf einem Core. – Dann entscheidet der Prozessor selbstständig, welcher Prozess zuerst läuft. – Das ist die Idee von Hyperthreading: Dass das um Größenordnungen schneller geht, als wenn der Kernel das macht.
* Du hast mehr als einen Kern und beide Kerne wollen auf die fifo schreiben. Dann entscheidet wieder der Kernel, wer zuerst darf. – Eigentlich umgekehrt Alle Prozesse, die auf eine Datei schreiben wollen, werden beendet. Der Kernel wählt dann wieder einen (Zufälligen) aus und lässt keinen zweiten mehr laufen, der die gleiche Datei schreiben will. – Das sorgt wieder dafür, dass es keine Probleme gibt.
* Dein Programm braucht mehr als 4ms Daten zu schreiben (bei ~5MiB). Dann darf dein Programm selbst entscheiden ob jemand in der Zwischenzeit schreiben darf: cat lässt das zu. Ich nehme an, echo nicht.

Das ist die ganze Idee hinter einem preemptiven Betriebssystem, dass es selbst ohne Programmiererinteraktion im Hintergrund entscheidet, welche Prozess in welcher Reihenfolge ausgeführt werden. Dass du als Programmierer nicht weißt, welche Reihenfolge das ist, macht paralleles Programmieren etwas komplizierter aber es ist kein Vergleich, wenn du dich selbst darum kümmern müsstest, welcher Prozess wann läuft. Microcontroller überlassen das üblicherweise dem Programmierer. – Deswegen gibt es da keine Komplexeren Anwendungen.

* Genaue Zahlen wann er wie lange wartet findest du unter cat /sys/kernel/debug/sched/*_granularity_ns
↓Ein paar sind die Anzahl der Threads die dein System hat.

[wanne]

Ob die nicht blockierende, die auf Vorrat schon mal Daten speichernde Named-Pipe, obwohl gerade (noch) niemand liest, gebraucht werden, das ist meine Frage.

Ich schreibe manchmal Programme die im Hintergrund was machen. Z.B. ein backup oder ein Messwert fürs monitoring:

Code: Alles auswählen

init_backupvars
while true
  do what=$(cat fifo)
  do_backup $what
done

Und dann halt das Programm selbst, dass schreibt, wenn es bereit für ein backup ist.
Da willst du eventuell mal lieber eins ausfallen lassen als dass dein ganzer Prozess hängt.

Oder ist es mit dem blockieren nicht ein vernünftiger Default, der einem auch sofort anzeigt, dass was schief ist, wenn etwas blockiert.

Die meisten Programmierer mögen es nicht, wenn einzelne Teile Fehlschlagen können, ohne dass sie sich das Überlegt haben, wie sie darauf reagieren. Lieber irgend wie weiter laufen als gar nicht. Deswegen sind die defaults bei vielen populären Sachen oft so, obwohl das andere vermutlich viel häufiger sinnvoller ist.