Diskussion:Interprozesskommunikation

Was hat RPC mit IPC zu tun? RPC ist für mich eine Technick der Netzwerkkommunikation. Sollte es sich hierbei um etwas anderes handlen, bitte dazuschreiben.--Termite 20:15, 12. Mai 2007 (CEST)

Man muss RPC ja nicht über netzwerk nutzen, sondern man kann ja auch RPC's zu lokalen Prozessen (oder Threads) erlauben. Es wird halt meist im Zusammenhang mit Netzwerk gesehen, aber das ist mE. nach nur ein Spezialfall. Týndur unterstützt RPC als die (momentan) einzige Form von IPC.--Bluecode 13:30, 13. Mai 2007 (CEST)

Evtl. könnte man es auch signal nennen, aber in dem Namen steckt ja eigentlich mehr als nur ein Funktionsaufruf in einen anderen Prozess/Thread.--Bluecode 13:36, 13. Mai 2007 (CEST)

Wo genau siehst du eigentlich den Unterschied zwischen Message Passing und Messages queues? Die wikipedia Artikel leuchten mir da jetzt auch nicht wirklich ein...--Bluecode 13:43, 13. Mai 2007 (CEST)

Ich hab den Wiki Artikel mal kurz überflogen MPI hat was mit Verteilten Systemen zu tun (was wohl auch nicht gemeint war) an sonsten ist es eher eine grundlegende beschreibung wie Nachrichten behandelt werden können siehe Beispiel ISR. Zurück zu den Message Queues. Ich kenn z.B. eine Implementierung, in der die Prozess mittels eines eindeutigen Namens drauf zugreifen. Ein Przess ist der Verarbeiter. Er wartet auf Nachrichten, die in der Queue eingestellt werden und holt sie zur weiterverarbeitung nacheinander ab. Wenn keine da sind wartet er solange bis eine eingestellt wurde. Andere Prozesse tragen Nachrichten in die Queue ein. Wobei je nach implementierung das Eintragen der Nachricht steuerbar ist (z.B. normale am Ende, Wichtige am anfang) Es ist glaubich sogar möglich mehrere Verarbeiter auf einer Queue arbeiten zu lassen. Aber das ist warscheinlich von Implementierung zu Implementierung unterschiedlich. --Termite 17:36, 13. Mai 2007 (CEST)

5te möglichkeit : der Thread der einen/mehrere Service(s) anbieten will wartet (blockierend per Syscall) einfach auf ankommende Anfragen, so ähnlich wie bei TCP-Server-Sockets. Die Anfrage könnte dann entweder im Thread selber bearbeitet werden (womit dann keine weiteren Anfragen parallel bearbeitet werden können) oder es wird ein Worker-Thread erstellt/aktiviert (wobei dann die Variante mit den OS-gemanagten-PopUp-Threads wieder interessanter klingt weil damit im Service eine Ebene weg fällt).