Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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.
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.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Ich nutze sie nur ganz selten. Der typische Anwendungsfall fuer mich ist, wenn ich ein laenger laufendes Programm von aussen fernsteuern will.
Use ed once in a while!
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Ich habe sie zwar vor langer Zeit mal ausprobiert, aber noch nie produktiv verwendet. Ich bin allerdings auch kein Profi in Sachen IT.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Ein Fall, wo mkfifo nützlich ist, wäre z.B. als Ersatz für Process Subsitution in dash und mksh.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Danke für eure Antworten.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Das FIFO Prinzip scheint bei named pipes nicht konsistent umgesetzt zu werden, zumindest konnte ich das auf meinem Mehrkernersystem nicht beobachten:
Wird dann der auslesnde Befehl, hier cat, in einem anderen Terminal ausgeführt, dann erhält man:
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äß
heißt es darin nämlich auch:
Die einzelnen Prozesse an einen einzigen bestimmten CPU Kern zu binden hat allerdings auch daran nichts geändert:
Und dann im anderen Terminal:
Auch den cat Prozess an nur einen CPU Kern zu binden, half auch nichts:
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.
Code: Alles auswählen
mkfifo testpipe
echo "0" > testpipe &
echo "1" > testpipe &
echo "2" > testpipe &
echo "3" > testpipe &
echo "4" > testpipe &
Code: Alles auswählen
cat testpipe
3
2
1
0
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
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.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.
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 &
Code: Alles auswählen
cat testpipe
2
1
3
0
4
Code: Alles auswählen
taskset -c 0 cat testpipe
4
0
3
2
1
Meine CPU hat noch Hyperthreading, aber daran kann es eigentlich auch nicht liegen, da taskset das meiner Meinung nach berücksichtigt.
- heisenberg
- Beiträge: 3666
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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:
Terminal 2:
Terminal 1 - Fortsetzung:
Wenn Du das im Vordergrund laufen lässt, dann bleibt die Reihenfolge erhalten:
Terminal 1:
Code: Alles auswählen
mkfifo testpipe
tail -f testpipe
Code: Alles auswählen
echo "0" > testpipe
echo "1" > testpipe
echo "2" > testpipe
echo "3" > testpipe
echo "4" > testpipe
Code: Alles auswählen
0
1
2
3
4
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Man kann sie auch erstmal nur zum Schreiben öffnen:heisenberg hat geschrieben:06.11.2023 22:25:29Wenn Du das im Vordergrund laufen lässt, dann bleibt die Reihenfolge erhalten:
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>&-
$
Code: Alles auswählen
$ cat pipe
0
1
2
3
4
$
- heisenberg
- Beiträge: 3666
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
@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.
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.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Was du hier machst ist tail zu benutzen. Versuch das mit cat, dann geht es nicht mehr.heisenberg hat geschrieben:06.11.2023 22:25:29Na 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:
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.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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.heisenberg hat geschrieben:06.11.2023 23:06:51@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.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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“).heisenberg hat geschrieben:06.11.2023 23:06:51Mir scheint es so, als ob die named Pipe anders als der Name "mkfifo" sagt, nur ein Element speichert und nicht eine Kette von Elementen.
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
Wenn man keine Probleme hat, kann man sich welche machen. ("Großes Lötauge", Medizinmann der M3-Hopi [und sog. Maker])
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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.GregorS hat geschrieben:07.11.2023 00:09:49Nein, FIFO steht für „first in, first out“ - es können sich also durchaus sehr viele Elemente in der Pipe befinden.heisenberg hat geschrieben:06.11.2023 23:06:51Mir scheint es so, als ob die named Pipe anders als der Name "mkfifo" sagt, nur ein Element speichert und nicht eine Kette von Elementen.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Btw: Im Kontext von Unix ist ``Element'' = ``Byte'' und ``Kette von Elementen'' = ``Folge von Bytes''. Das Prinzip ist aber natuerlich das gleiche.
Use ed once in a while!
- heisenberg
- Beiträge: 3666
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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.
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.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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:
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:
Am besten, du liest dir mal die Manpage fifo(7) durch, da wird das erklaert.Manpage mkfifo(3) hat geschrieben: 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.
Use ed once in a while!
- heisenberg
- Beiträge: 3666
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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?
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?
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Was meinst du damit - werden named pipes gebraucht oder werden blockierende named pipes gebraucht?heisenberg hat geschrieben:07.11.2023 17:36:40Da 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.
Für blockierende named pipes? Als Ersatz für Dateien z.B.: Mein Beispiel von oben, die fehlende Process Substitution in mksh und dash:Ü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?
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
- Beiträge: 3666
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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.
Ob die nicht blockierende, die auf Vorrat schon mal Daten speichernde Named-Pipe, obwohl gerade (noch) niemand liest, gebraucht werden, das ist meine Frage.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Das ist ja eine interessante Notation. Gibt es einen bestimmten Grund, warum du hier eine Brace Expansion verwendest, statt `mkfifo f1 f2' zu schreiben?
Use ed once in a while!
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Das simple hintereinanderreihen ist mir gedanklich jetzt gar nicht gekommen, sonst hätte ich es gemacht. Siehe `rm {f1,f2}'!?
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
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.
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.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: Benutzt ihr in der Kommandozeile explizit named pipes oft oder eher selten oder gar nicht?
Ich schreibe manchmal Programme die im Hintergrund was machen. Z.B. ein backup oder ein Messwert fürs monitoring:heisenberg hat geschrieben:07.11.2023 20:21:14Ob die nicht blockierende, die auf Vorrat schon mal Daten speichernde Named-Pipe, obwohl gerade (noch) niemand liest, gebraucht werden, das ist meine Frage.
Code: Alles auswählen
init_backupvars
while true
do what=$(cat fifo)
do_backup $what
done
Da willst du eventuell mal lieber eins ausfallen lassen als dass dein ganzer Prozess hängt.
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.Oder ist es mit dem blockieren nicht ein vernünftiger Default, der einem auch sofort anzeigt, dass was schief ist, wenn etwas blockiert.
rot: Moderator wanne spricht, default: User wanne spricht.