Port Handwerk Systeme zu Libcaf

Question

Ich habe derzeit eine Anwendung, die handgefertigte Schauspieler verwendet. Mein Plan ist, es in libcaf zu portieren.

Der aktuelle Status ist: Ich habe eine große globale Nachrichtenwarteschlange, wo meine Systeme (aka Akteure) abonnieren, um ihre Nachrichten zu erhalten. Sie antworten mit Nachrichten an diese globale Warteschlange.

Das ganze System ist eine Echtzeitanwendung, die auf Linux rt-Preempt Kernel läuft. Der GUI-Thread ist selbst ein System (Akteur), hat jedoch keine RT-Priorität.

Im Moment müssen meine Systeme die Empfänger ihrer Nachrichten nicht kennen, weil die Empfänger sich für ihre gesuchten registrieren.

Meine Portierung Idee ist wie folgt: Ich verwende einen globalen Akteur als Ersatz für meine globale Nachrichtenwarteschlange und es behandelt die Registrierung für die Nachrichten. Auf diese Weise kann ich ein einfaches Protokoll der Nachrichten für den Debugging-Zweck erhalten, und ich muss nicht alle Akteure alle möglichen Ziele wissen lassen.

Ich habe ein IO-System (Canbus), das den Kontakt zur realen Welt handhabt.

In meinem aktuellen System spawne ich das GUI-Thread + System. Es wartet auf die Initialisierung von RT. Nachdem der GUI-Thread erzeugt wurde, wechsle ich auf RT Preempt Priority und erstelle die anderen Systeme, vergesse den Stack und so weiter. Wenn alles eingerichtet ist, benachrichtige ich die GUI, dass RT aktiv ist. Jetzt ist mein System initialisiert.

Wenn einige fatale Dinge passieren oder das System herunterfahren muss, sende ich eine Nachricht und alle Systeme heruntergefahren und alle Threads werden verbunden.

Meine Fragen sind: Wie kann ich die GUI Akteur/Thread aus dem RT-Thread in libcaf trennen? Würden Sie empfehlen, die GUI in einem separaten Prozess zu verzweigen? Kann ich Schauspieler auf verschiedenen RT Priority Threads spawnen?

EDIT: Ich finde die spawn Option detached. Sind die gespawnten Schauspieler (Kinder eines abgespaltenen Schauspielers) auf demselben Faden?

Answer 1

Der aktuelle Status ist: Ich habe eine große globale Nachrichtenwarteschlange, wo meine Systeme (aka Akteure) abonnieren, um ihre Nachrichten zu erhalten. Sie antworten mit Nachrichten an diese globale Warteschlange.

Im Moment müssen meine Systeme die Empfänger ihrer Nachrichten nicht kennen, weil die Empfänger sich für ihre gesuchten registrieren.

CAF hat Publish/Subscribe-Gruppen, die hier gut passen. Die Verbraucher schließen sich einfach einer bekannten Gruppe an und die Produzenten schicken sie dorthin. Damit erhalten Sie genau die Entkopplung von Sendern und Empfängern, die Sie suchen.

Wenn einige fatale Dinge passiert, oder das System herunterzufahren braucht, ich sende eine Nachricht und alle Systeme heruntergefahren und alle Fäden verbunden bekommen.

Es gibt zwei Möglichkeiten, dies einfach zu erreichen. Eine besteht darin, die Gruppe zu verwenden, aber das erfordert, dass alle Ihre Akteure bei schwerwiegenden Systemzuständen angemeldet sind. Alternativ könntest du einen einzelnen "root" -Aktor verwenden, um alle anderen Schauspieler zu spawnen und immer das linked Flag während des Spawns verwenden. Auf diese Weise tötet das Töten des Root-Actors seine Kinder rekursiv.

Wie kann ich den GUI Actor/Thread vom RT Thread in libcaf trennen? Würden Sie empfehlen, die GUI in einem separaten Prozess zu verzweigen?

In 0.14 müssen Sie die GUI in einen eigenen Prozess verschieben und dann über remote_actor eine Verbindung zu ihr herstellen. Als Nebeneffekt entkoppelt dies die GUI von der Anwendungslogik, und Abstürze in der GUI wirken sich nicht auf andere Teile Ihres Systems aus. Natürlich bezahlen Sie in diesem Szenario für die Kommunikation und Serialisierung von localhost.

Mit dem kommenden 0.15 könnten Sie auch andere actor_system Instanzen mit getrennten Schedulern verwenden. Dies könnte Ihnen ein wenig Aufwand ersparen, aber ich würde es trotzdem bevorzugen, die GUI in einen eigenen Prozess zu verschieben.

Übrigens müssen Sie fork nicht tatsächlich verwenden. Sie können einfach Ihre Anwendung, publish einen Akteur an einen Port ausführen und dann Ihre GUI über remote_actor verbinden.

Ich finde die Spawn-Option gelöst. Sind die gespawnten Schauspieler (Kinder eines abgespaltenen Schauspielers) auf demselben Faden?

Ein unabhängiger Akteur wird immer in einem eigenen Thread ausgeführt.

Kann ich Schauspieler auf verschiedenen RT Priority Threads spawnen?

Kurze Antwort: Nein. CAF verwendet die Schnittstelle std::thread, die tragbar ist, RT-Prioritäten jedoch nicht unterstützt. Das Hinzufügen von Prioritäts-Flags beim Abtrennen von Actors ist möglich, aber plattformspezifische Features wie diese stehen nicht auf unserer ToDo-Liste.

Das heißt, natürlich würden wir Patches für CAF akzeptieren, die RT-Prioritätsunterstützung hinzufügen.