Zwei Syscalls.
Nur zum eintragen und austragen des Services auf der Sterbebenachrichtigungsliste des Client-Prozess.
Richtig. Wenn alles korrekt aufgeräumt wird, bleibt es ja aber auch bei diesen zwei Syscalls, weil beim Prozessende kein Server mehr benachrichtigt werden will.
und ganz kostenlos bekommt man Korrektheit meistens nicht.
Da sprichst Du wahr! Es bleibt nur die Frage wie hoch der Preis sein darf/muss.
Vielleicht solltest du mal umgekehrt rangehen: Wie billig soll es denn noch werden? Ein Syscall kostet sowieso schon im Vergleich zu den ganzen IPC-Tätigkeiten des Servers nicht sehr viel. Er würde genau einmal pro open/close passieren, was tendenziell auch nicht sehr oft passiert, wenn man mit read/write-Aufrufen vergleicht. Ich bin mir ziemlich sicher, dass der Syscall schon damit nicht im Ansatz ins Gewicht fällt - das (seltene) open wird wesentlich kompliziertere und teurere Sachen machen.
Ich weiß nicht vor was genau du beim Syscall Angst hast (ist doch nur ein Ringwechsel, kein Kontextwechsel, oder?), aber wenn es um die Anzahl der Syscalls geht, könntest du einen kombinierten Syscall aus IPC und in die Liste ein-/austragen machen. Nicht, dass ich das für sinnvoll hielte, das wäre Design für eine minimale Optimierung geopfert.
Ich würde in jedem Prozess-Verwaltungs-Struct ein paar Plätze für, im Sterbefall, zu benachrichtigende PIDs bereithalten und wenn die nicht reichen dann muss auf eine zusätzliche große Liste verwiesen werden (so ähnlich wie im inode von ext2). Ein typisches Programm wird kaum über "file", "console" und "tcp" hinauskommen so das z.B. 6 Direkt-Einträge meistens reichen sollten.
Wozu so kompliziert? Nimm doch gleich eine Liste. Ist genauso schnell wie das Array (du brauchst keinen Direktzugriff auf ein Element per Index) und wesentlich einfacher zu implementieren als eine Mischform.
Über Vererbung von Ressourcen hab ich in der Tat noch nicht nachgedacht. Wenn dann würde ich das auf explizite Anweisung der Ersteller-Clients an den Service hin machen wollen, nur UNIX-like ist das sicher nicht. Braucht man sowas überhaupt?
Wenn du POSIX haben willst, ja. exec() gibt eben alle Deskriptoren an die Kindprozesse weiter (es sei denn, FD_CLOEXEC ist gesetzt) und wenn du das nicht machst, laufen viele Programme nicht richtig. Wenn du kein POSIX willst, kannst du die Anwendungsfälle für das Vererben von Dateideskriptoren wohl besser über deine eigene IPC-API abdecken.
Wie macht tyndur das aufräumen der Ressourcen im Fehlerfall eigentlich?
Der Kernel kann einen RPC-Aufruf machen, wenn ein Prozess beendet wird. Ich glaube aber nicht, dass das tatsächlich benutzt wird (außer für die Implementierung von waitpid, aber das hat ja mit diesem Thema nichts zu tun).
Kann tyndur Ressourcen-Vererbung?
Nein, das ist uns zu spät aufgefallen, dass man das für POSIX braucht und deswegen passt es überhaupt nicht in unser Design.
Wobei wir ja mit LIOv2 die ganze Dateiverwaltung neu schreiben (und nebenbei in den Kernel verschieben). Damit sollte es dann am Ende gehen.