Thema: Woher weiß Prozess A welcher Prozess ... ?

[bitmaster]

Hallöchen,

wie ihr ja alle wisst arbeite ich zz. unter Hochdruck an OS-64. Und es bleiben mir noch fast genau 4 Wochen um die neue Build fertig zu stellen.

Eine Implementation gefällt mir aber ganz und gar nicht. Nur weiß ich leider nicht welche andere und vor allen dingen bessere Möglichkeit es gibt. Ich möchte das Problem an einem Beispiel erläutern:

Prozess A soll "Hallo Welt!" auf den Schirm zaubern. Nun, dazu wird eine Routine der Bibliotheken aufgerufen, die dann per IPC den Grafiktreiber anspricht, genauer gesagt den Prozess, der den Grafiktreiber darstellt (sagt man das so  ). Nur woher weiß jetzt Prozess A (bzw. diese Bibliotheksroutine) welcher Prozess der Grafiktreiber ist?

Und genau das gefällt mir an OS-64 nicht. Zz. wird es so gemacht:

Wenn der Prozess, der den Grafiktreiber darstellt startet, gibt er sich über Bibliotheksfunktionen den Namen "display". Der Prozess A muss jetzt auch über Bibliotheksfunktionen nach einem Prozess mit dem Namen "display" suchen und lässt sich dessen PID ausgeben. Jetzt sendet er die Message mittels IPC an den Prozess mit der PID (also an den Grafiktreiber) und die Message "Hallo Welt!" erscheint auf dem Bildschirm.

Um an die Namen zu kommen muss er eine Message an den Prozess mit der PID 1 senden, die für ihn die PID raussucht. Das ganze Senden und Empfangen dauert praktisch ewig (und würde bei einer GUI sicherlich sichtlich zu langsam sein).

Jetzt meine Frage: Gibt es eine schnellere und bessere Variante an die PID eines gewünschten Prozesses zu kommen? Bzw. wie macht ihr das in eurem OS? Evtl. könnt ihr mir ja helfen.

Vielen dank!!!

bitmaster

[kevin]

LOST macht es im wesentlichen genauso.

Um an die Namen zu kommen muss er eine Message an den Prozess mit der PID 1 senden, die für ihn die PID raussucht. Das ganze Senden und Empfangen dauert praktisch ewig (und würde bei einer GUI sicherlich sichtlich zu langsam sein).

Die PID mußt du für jeden Treiber nur einmal beim Start des Prozesses abfragen, danach hast du sie lokal in einer Variablen gespeichert.

[bitmaster]

@taljeth: danke

Die PID mußt du für jeden Treiber nur einmal beim Start des Prozesses abfragen, danach hast du sie lokal in einer Variablen gespeichert.

Aber was ist wenn der Treiber beendet wird und ein neuer / anderer Treiber gestartet wird. Der bekommt dann ja evtl. die gleiche PID. Und wenn man die PID gespeichert hat und nicht auf den Namen prüft, dann würde ja der neue (evtl. falsche) Treiber angesprochen werden.

Oder sehe ich da irgendwas falsch?

bitmaster

[jgraef]

Hi,

Ich hatte im ersten Kernel von meinOS eine Port-Abstraktion. D.h es lag eine feste Zuordnung von Dienst=>Port vor und wenn der Treiber nun startet wird mithilfe des Ports die PID ermittelt. Das ist aber im Prinzip das gleiche wie ihr verwendet und ergibt auch die gleichen Probleme.

Mein neuer Kernel benutzt die IPC Methoden der XSI-Erweiterung des ISO-C-Standards. Dabei ist die Kommunikation nicht mit der PID gebunden. Im Falle des Grafiktreibers, erstellt dieser eine Messagequeue mit dem Key ftok("/dev/screen",'S') (wichtig ist nur dass der Key immer gleich ist). Um nun ein Zeichen auf den Bildschirm auszugeben muss der Client-Prozess die Messagequeue öffnen (dafür muss er natürlich den Key wissen, oder wie er mit ftok gebaut wird). Nun kann er Nachrichten an den Treiber schicken. Empfangen wäre ja sinnlos und um dies zu verhindern (damit Clients nicht die Messages aus der Queue klauen) kann man einfach die Zugriffsrechte ändern.

Der Vorteil ist, dass sich die Messagequeue nicht ändert, wenn der Grafiktreiber neugestartet wird. D.h der Client-Prozess kann weiterschreiben.

[Korona]

Ja, das ist ein Problem, wenn du zulässt dass eine PID nach dem Beenden des Prozesses nochmal vergeben wird.
Eine Lösung wäre PIDs nicht mehrmals zu vergeben. (dazu wäre es vorteilhaft mindestens 64 Bit oder gar 128 Bit lange PIDs verwenden; ich nutze dieses Modell)
Eine andere Möglichkeit ist, nur die Hälfte der Bits aus denen die PID besteht zur Bestimmung des Prozesses zu verwenden und die andere Hälfte als eindeutigen Schlüssel für den Prozess zu verwenden. Bei einem Systemcall kann der Kernel dann den Schlüssel den er aus der PID entnimmt mit dem Schlüssel der in der Taskstuktur gespeichert ist vergleichen. Stimmen sie überein so ist die PID gültig, andernfalls bricht der Kernel mit einem Fehler ab. Windows verwendet AFAIK dieses Modell.

[kevin]

Die PID mußt du für jeden Treiber nur einmal beim Start des Prozesses abfragen, danach hast du sie lokal in einer Variablen gespeichert.

Aber was ist wenn der Treiber beendet wird und ein neuer / anderer Treiber gestartet wird. Der bekommt dann ja evtl. die gleiche PID. Und wenn man die PID gespeichert hat und nicht auf den Namen prüft, dann würde ja der neue (evtl. falsche) Treiber angesprochen werden.

Du könntest den Nutzer beispielsweise beim Kernel registrieren lassen, so daß er beim Beenden des Treiberprozesses vom Kernel eine Nachricht bekommt.

[bitmaster]

OK vielen dank!!! Ich werde dann mal schauen. 

bitmaster