Thema: Neuen Prozess laden/starten (Mikrokernel)

[Svenska]

Du akzeptierst also weder stdin/stdout/stderr, noch Sockets, noch FIFOs (mknod p) als valide Beispiele für Dateideskriptorsharing mit der Begründung, es handle sich ja nicht um "richtige" Dateien.

Gut, dann implementiert das halt alles nicht über das VFS und macht für jeden Teil ne eigene API auf. Kann nur gut zum Portieren vorhandener Software sein...

Mehr oder weniger sinnvolle Beispiele findet ihr bestimmt, wenn ihr Realwelt-Software benutzt, die das nutzt. Mir fiele noch die Kommunikation mit Plugins ein, aber solcherart "Dateien" werden dann ja sinnvollerweise wieder über Sockets verwendet...

[erik.vikinger]

Hallo,

Du akzeptierst also weder stdin/stdout/stderr, noch Sockets, noch FIFOs (mknod p) als valide Beispiele für Dateideskriptorsharing mit der Begründung, es handle sich ja nicht um "richtige" Dateien.

Ganz genau! Es geht um den File-Pointer der von mehreren Prozessen gleichzeitig benutzt werden soll und eben den gibt es bei Streams, Sockets, FIFOs usw. nicht, zumindest nicht in der Form wie bei echten Dateien.

Gut, dann implementiert das halt alles nicht über das VFS und macht für jeden Teil ne eigene API auf. Kann nur gut zum Portieren vorhandener Software sein...

Also ich sehe nur Dateien und Streams (TCP-Socket und Pipes/FIFOs sind IMHO welche), UDP-Sockets sind noch was eigenes da Paket-orientiert. Das hinter der libc-API zu verbergen stelle ich mir nicht so schwer vor (womit dann auch wieder das Portieren möglich ist), wenn du da Probleme siehst dann schreib die doch mal hier rein.

Mehr oder weniger sinnvolle Beispiele findet ihr bestimmt, wenn ihr Realwelt-Software benutzt, die das nutzt.

Also das es ein sinnvolles Beispiel für das gemeinsame benutzen echter Dateien aus mehreren Prozessen gibt bezweifle ich immer noch, die zu erwartenden Probleme hab ich doch gestern Nachmittag erläutert. Alles andere lässt sich IMHO auf Streams abbilden.


Grüße
Erik

[kevin]

Ich möchte mich nicht festlegen, wie sinnvoll das Beispiel sein wird, aber ich bin mir relativ sicher, dass du irgendwann beim Portieren irgendeiner Software die Hände über dem Kopf zusammenschlagen wirst, weil genau das benutzt wird.

[Jidder]

Sollen generell zwei Prozesse nicht die selbe Datei zum beliebigen Schreiben öffnen dürfen?

[kevin]

Naja, dafür findet man sicher viele Beispiele. Soweit ich das verstehe, geht es hier immer noch darum, dass zwei Prozesse nicht nur auf dieselbe Datei, sondern auch noch auf dieselbe Open File Description zugreifen, also denselben Dateizeiger haben. Da wird die Luft schon dünn, wenn man alles rausstreicht, was sequenziell ist...

[erik.vikinger]

Hallo,

Ich möchte mich nicht festlegen, wie sinnvoll das Beispiel sein wird, aber ich bin mir relativ sicher, dass du irgendwann beim Portieren irgendeiner Software die Hände über dem Kopf zusammenschlagen wirst, weil genau das benutzt wird.

Entschuldige, aber das ist leeres geschreibsel. Wenn Du kein Beispiel kennst dann schreib das einfach.
Zur Not kannst Du Dir auch gerne ein fiktives Szenario ausdenken aber dann musst Du auch erklären wie die Probleme, die ich gestern Nachmittag erläutert habe, zu vermeiden sind.

Sollen generell zwei Prozesse nicht die selbe Datei zum beliebigen Schreiben öffnen dürfen?

Nicht zum beliebigen beschreiben mit einem gemeinsamen Datei-Pointer. Dafür kann ich mir wirklich keine sinnvolle Anwendung vorstellen (die Prozesse müssten sich einigen wer was wann macht sonst ist das Ergebnis in der Datei unvorhersehbar). Paralleles Schreiben in die selbe Datei aber mit unabhängigen Datei-Pointern kann ich mir zumindest theoretisch vorstellen aber unterstützen möchte ich das frühestens dann wenn ich das wirklich brauche (und das sehe ich noch nicht). Das mehrere Prozesse an eine Datei was anhängen (z.B. Log-Datei) ist ein sicher alltägliches Szenario das ich auch auf jeden Fall unterstützen möchte.


Grüße
Erik

[erik.vikinger]

Hallo,

Soweit ich das verstehe, geht es hier immer noch darum, dass zwei Prozesse nicht nur auf dieselbe Datei, sondern auch noch auf dieselbe Open File Description zugreifen, also denselben Dateizeiger haben. Da wird die Luft schon dünn, wenn man alles rausstreicht, was sequenziell ist...

Da dürfte die Luft noch weniger als nur dünn werden.
Wenn wir uns darauf einigen können das man den Datei-Pointer nicht in mehreren Prozessen gleichzeitig braucht so das dieser in der libc bleiben kann dann dürfte das Vererben in einem Micro-Kernel-OS schon deutlich einfacher werden.


Grüße
Erik

[kevin]

Entschuldige, aber das ist leeres geschreibsel. Wenn Du kein Beispiel kennst dann schreib das einfach.
Zur Not kannst Du Dir auch gerne ein fiktives Szenario ausdenken aber dann musst Du auch erklären wie die Probleme, die ich gestern Nachmittag erläutert habe, zu vermeiden sind.

Nachdem dir alle meine Beispiele nicht gut genug waren, kenne ich wohl keins mehr. Es wird schwer, noch ein sinnvolles Ergebnis zu produzieren, wenn man tatsächlich Seeks drin hat. Aber wie gesagt, ich würde mich wundern, wenn es nicht trotzdem irgendein Stück Software gäbe, das sowas benutzt. Ich persönlich bin nur noch nicht drübergestolpert.

[erik.vikinger]

Hallo,

Nachdem dir alle meine Beispiele nicht gut genug waren, kenne ich wohl keins mehr.

Deine Beispiele waren schon gut und wichtig, aber es waren eben keine Beispiele für echtes Datei-Sharing mit gemeinsamen Datei-Pointer für parallelen Zugriff und alles andere lässt sich über Streams leichter realisieren.

Es wird schwer, noch ein sinnvolles Ergebnis zu produzieren, wenn man tatsächlich Seeks drin hat.

Das schreibe ich doch nun schon seit mehreren Seiten in diesem Thread.

Aber wie gesagt, ich würde mich wundern, wenn es nicht trotzdem irgendein Stück Software gäbe, das sowas benutzt. Ich persönlich bin nur noch nicht drübergestolpert.

Klar, kein Blödsinn ist so blöd das den nicht doch mal irgendjemand macht.
Im Ernst, logisch bist Du noch nicht über sowas gestolpert. Ich hab auch nicht wirklich damit gerechnet das Du da ein Beispiel nennen kannst. Ich wollte einfach nur das wir fürs Protokoll festhalten das man echte Dateien zwar vererben kann aber das die trotzdem immer nur von einem Prozess aktiv benutzt werden, genau das macht es aber möglich die Datei in der libc zu managen und den VFS simpel zu halten.

Du hast geschrieben das tyndur überhaupt gar keine Vererbung kann, dafür habt ihr aber schon ne Menge an POSIX-Programmen portiert. Also entweder wird das nicht so häufig benutzt wie Du uns weiß machen möchtest oder es liefert nicht die Basis-Funktionalität oder es ist nicht so schwer den Quell-Code von solcherlei gePOSIXe zu befreien.


Grüße
Erik

[kevin]

Zumindest bei Input-Streams sehe ich nicht, wie du noch sehr weit von der Behandlung allgemeiner Dateien entfernt wärst. Du hast dann ja schon eine gemeinsame Position. Das einzige, was du verbietest, sind Seeks, aber einen Vorteil im Sinn leichterer Implementierbarkeit bringt dir das nicht mehr. Und wenn du es für Input hast, ist der Sprung zu Output auch nicht mehr groß.

tyndur kann keine POSIX-Programme, die andere Prozesse starten (mangels fork), insofern wollen diese Programme natürlich auch keine Deskriptoren vererben. Die einfachen Fälle kann man durch die nativen Funktionen ersetzen, aber wenn ich mich grad nicht täusche, hängt beispielsweise der Port von git an irgendsowas fest, weil er auch noch irgendwie mit dem Kindprozess kommunizieren will.

[erik.vikinger]

Hallo,

Zumindest bei Input-Streams sehe ich nicht, wie du noch sehr weit von der Behandlung allgemeiner Dateien entfernt wärst.

Ließt Du meine Beiträge auch oder immer nur den letzten? Vor fast genau 3 Stunden habe ich beschrieben wie ich mir das für Streams vorstelle, ich kann da keine Gemeinsamkeiten mit Dateien entdecken.

tyndur kann keine POSIX-Programme ....

Ich empfinde es trotzdem als respektable Leistung wie weit ihr gekommen seit.


Grüße
Erik

[kevin]

Und ich kann keine Unterschiede zu Dateien entdecken, außer eben dem fehlenden Seek. Statt dem Inhalt, der gerade in der Pipe ist (oder was auch immer du als Stream anerkennst), würde bei einer Datei die Quelle eben die komplette Datei bis zum EOF anbieten. Im Zweifelsfall kann die Datei während der Laufzeit auch wachsen, genau wie die Pipe auch. Wo genau soll denn jetzt der Unterschied sein, außer dass ich in der Pipe nicht seeken kann?

[FlashBurn]

Ich habe mal ein wenig im INet gesucht und so wie ich das mit fork() und dem Vererben von z.B. Sockets bei nem Webserver verstanden habe funktioniert das so, dass der Parent sein Socket nach dem fork() schließt und dann nur noch das Kind alleine den Socket nutzt.

Wenn das bei annähernd 100% aller Fälle so ist (was ich nicht glaube) dann ist das Problem doch praktisch nicht vorhanden?!

Ich will darauf hinaus, das selbst bei anderen Sachen (wie z.B. Sockets) nie der Fall eintritt, dass mehrere Prozesse gleichzeitig (mit ein und dem selben Dateidiskriptor/-pointer) lesend zugreifen.

Wenn ich mich nicht irre, dann sind ja C-Library und POSIX zwei unterschiedliche Sachen oder?

Edit::

Nachdem was ich zu fork() und dup() gefunden habe, ist fork() der einzige Fall wo wirklich der Dateipointer auch geshared wird (und es wird auch gesagt, das gleichzeitiger Zugriff nicht sequentiell ist) und bei dup() wird zwar die Position übernommen, aber es ist ein eigenständiger Dateidiskriptor, sprich es ist ein "fork" (eine Momentaufnahme) des Dateidiskriptors.

[Svenska]

Richtig, dein Socketbeispiel wird in der Regel so implementiert. Das geht allerdings nur solange gut, wie das Kind sich auch vollständig um das Socket kümmern kann.

Bei Sachen wie CGI/FastCGI mit Gefolge wie AJAX stelle ich mir das schon etwas schwierig vor, wenn die Kinder voneinander abhängen. Sie haben nämlich prinzipiell die gleichen Eltern, aber kennen sich nicht. In dem Fall kann ich es mir schon vorstellen, dass ein Kindprozess sagt "ich will nicht mehr", das Socket schließt und an den Elternprozess "zurückgibt". Letzterer kann das Socket ja auch solange offenlassen, bis das betreffende Kind gestorben ist...

POSIX ist ein Standard, der (u.a.) ein Interface beschreibt. Implementierst du dieses Interface in deiner libc, dann stellt deine libc eine POSIX-Implementation bereit. Andernfalls stellt deine libc eine native API (oder sogar ABI) bereit, und deine POSIX-Implementation liegt in einer libposix, die als Wrapper eingesetzt wird. Dann musst du zwei APIs pflegen.

Das eine ist ne Implementation, das andere nur eine Schnittstellenbeschreibung.

Gruß,
Svenska

[FlashBurn]

POSIX ist ein Standard, der (u.a.) ein Interface beschreibt. Implementierst du dieses Interface in deiner libc, dann stellt deine libc eine POSIX-Implementation bereit. Andernfalls stellt deine libc eine native API (oder sogar ABI) bereit, und deine POSIX-Implementation liegt in einer libposix, die als Wrapper eingesetzt wird. Dann musst du zwei APIs pflegen.

Für mich ist beides ein Standard der bestimmte Sachen vorgibt (z.B. für C printf() und für POSIX ein fork()).

Bei Sachen wie CGI/FastCGI mit Gefolge wie AJAX stelle ich mir das schon etwas schwierig vor, wenn die Kinder voneinander  abhängen. Sie haben nämlich prinzipiell die gleichen Eltern, aber kennen sich nicht. In dem Fall kann ich es mir schon vorstellen, dass ein Kindprozess sagt "ich will nicht mehr", das Socket schließt und an den Elternprozess "zurückgibt". Letzterer kann das Socket ja auch solange offenlassen, bis das betreffende Kind gestorben ist...

Also entweder nutzt der Elternprozess die "Datei" nicht während das Kind läuft oder es schließt sie sobald geforkt wurde. Wie soll das "zurückgeben" funktionieren?

Ich hatte die verrückte Idee (nur mal als Grobkonzept) fork() als threadCreate() und exec() als processCreate() umzusetzen.

Bei exec() sehe ich die wenigsten Probleme, da ich einfach bei meiner processCreate() eine Möglichkeit vorsehen kann, das man Dateidiskriptoren an den neuen Process weitergibt und dann wird einfach der laufende Thread beendet.

Bei fork() ist es etwas schwieriger. Erstmal müsste man für alle Dateidiskriptoren einen RefCount haben (wenn der ElternThread die Datei schließt, das der KindThread noch damit arbeiten kann) und ansonsten müsste die Implementation der C-Library ThreadSafe sein.

Welche Probleme würden euch sonst noch einfallen (was fork() als neuen Thread betrifft)?

[kevin]

Globale Variablen werden von allen Threads geteilt, während sie nach einem fork() maximal COW sind. Wenn ein Prozess schreibt, ändert sich also für den anderen nichts. Insofern ist threadCreate() nicht wirklich eine geeignete Implementierung für fork().

[erik.vikinger]

Hallo,

Und ich kann keine Unterschiede zu Dateien entdecken, außer eben dem fehlenden Seek. ....

Es gibt bei Dateien den wahlfreien Zugriff auf beliebige Bytes, eben das seek, und bei Streams/Pipes u.ä. gibt es das nicht. Dort bekommt das Ziel einfach die Daten der Reihe nach zugestellt und kann die entweder nehmen (read) oder ignorieren (skip) aber das Ziel hat keine Möglichkeit zu bestimmen welche Daten es wann gerne hätte. Mag sein das man das von der API her auf Dateien abbilden kann (so wie es auf der libc-API-Ebene ja auch sein soll) aber ich möchte Streams/Pipes u.ä. intern anders implementieren als Dateien, so wie ich das beschrieben hatte, und damit wären die Gemeinsamkeiten dann vorbei. Außerdem bleibt damit das VFS von solchen Sonderformen befreit, was einer meiner Hauptgründe ist.

Klar kann man alles als eins betrachten aber genau das will ich nicht, ich möchte 2 verschiedene Wege und jeden für seine Aufgabe passend optimieren und ich behaupte das ich damit in Summe sogar weniger Code haben werde weil beide Wege recht simpel bleiben können. Zusätzlich möchte ich mir gerne den Performancevorsprung durch passende Technik sichern.


Grüße
Erik

[Svenska]

OT: "Vorsprung durch Technik"