eibd(war bcusdk) Fork -> knxd

[Zepp]

ein sehr schöne Möglichkeit für portable multithreaded Anwendungen ist das QP Aktor framework:

http://state-machine.com/win32/index.php

http://state-machine.com/linux/index.php

[Smurf]

Sieht auf den ersten Blick nicht schlecht aus. Zepp: Du willst dir doch bestimmt diesen Rewrite auf die Fahnen schreiben ..?

[Zepp]

Ich bin dafür leider vollkommen ungeeignet, da ich keine Ahnung von C++ habe. Ich setze das QP-C (ohne ++) framework schon einige Jahre im embedded-Bereich ein und bin davon sehr begeistert. Für die meisten Aufgaben ziehe ich QP jederzeit einem RTOS vor. Ob es auch für den eibd die richtige Wahl ist kann ich nicht beurteilen, der Umstieg auf ein event/actor/return-to-completion (RTC) Modell würde eventuell dazu führen, dass einiges umgebaut werden muss.

Ich kenne pthsem nicht, aber

"Pth (...) provides non-preemptive priority-based scheduling for multiple threads of execution"

könnte ein Hinweis darauf, sein, dass der Weg nicht soweit ist.

"pthsem is an extend version, with support for semaphores added."

eher ein Hinweis, dass dem nicht so ist.

[Smurf]

Der in knxd verwendete C++-Anteil ist relativ überschaubar (keine Templates, kein Operator Overloading, etc.).

Die Semaphoren in pthsem werden eigentlich nur verwendet, um zu signalisieren, dass eine Queue nicht leer ist – was man wiederum nur deswegen braucht, weil der einzelne Aktor auf mehrere Events lauschen "muss" (meistens: eine Queue, ein Objekt dass der Task beendet werden soll, und einen Timeout o.Ä.) und die Queue-Abstraktion in pth(sem) keine Eventquelle ist. Das kann man um Einiges zielführender programmieren, d.h. jeder Aktor bekommt genau eine Queue und höchstens einen Timeout – und wenn man mehr braucht, will man eigentlich mehr als einen Aktor. :-P

QP-C sieht so aus, als könnte es genau dieses Modell perfekt unterstützen.

[Zepp]

Wenn eibd sowieso schon Aktoren nutzt, drängt es sich natürlich auf auch ein Aktor-framework einzusetzen. Es gibt übrigens auch QP-C++ (und einige andere Aktor Implementierungen für C++ die ich aber nicht kenne)

[Smurf]

Ich habe mir mal den QP-C++-Code angesehen. Sagen wir mal so: Idiomatisches C++ sieht ein bisschen anders aus. :-/

Zu ihrer Ehrenrettung muss man dazusagen, dass QP aus dem Embedded-Bereich kommt und sich "idiomatisches C++" und "optimierter Code für embedded-Systeme" gegenseitig so'n bisschen ausschließen. Aber diese Erkenntnis hilft bei knxd nur bedingt was.

[Zepp]

Könntest du mal ein konkretes Beispiel nennen? Ich bin mir sicher, dass Herr Samek gute Gründe hatte das Framework genau so zu implementieren wie es ist.
Ich kenne nur die C Version und der Code ist mit der beste den ich jeh gesehen habe.

Wie ist deine Meinung zum eibd-code? Gefällt dir der besser?

[Smurf]

Konkretes Beispiel: Objekte mit statischen Funktionen und "me" als erstem Parameter, statt normale Methoden mit implizitem "this".
Zeiger auf Methoden sind syntaktisch ein bisschen nervig, aber wirklich kein Hexenwerk.

Ich sehe mir das demnächst mal genauer an (und frage ggf. nach), aber erst wenn Sourceforge wieder funktioniert.

[Zepp]

Ich vermute, dass der Grund dafür ist, die C und C++ Version möglichst ähnlich zu halten. Mit dem expliziten "me" und structs die als ersten member die struct der Basisklasse enthalten wird in QP-C die Objektorientierung implementiert.

struct Baseclass {
   ...
}

struct Childclass {
   struct Baseclass super;
   ...
}

Baseclass_foo(struct Baseclass *me, params)
Childclass_foo(struct Childclass *me, params)

Childclass c;

Baseclass_foo((struct Baseclass *)&c, ...)

[Smurf]

Baseclass_foo((struct Baseclass *)&c, ...)

Auch diesen Code verstehe ich nicht wirklich, schließlich tut

Baseclass_foo(&c->super, ...)

genau dasselbe -- ist aber wenigstens an dieser Stelle typsicher. Mit C++ bekomme ich die umgekehrte Richtung mit einem <dynamic_cast> gebacken – aber wenn man den Code so schreibt, dann geht dieser Vorteil verloren.

Egal. Kann man alles beheben und/oder damit leben.

Es gibt halt zwei fundamental verschiedene Alternativen an dieser Stelle – entweder ein Framework wie QP-C, das auf C-Kompatibilität setzt, oder man verwendet gleich die nativen Features von C++11 (bzw. Boost:. Letzteres hätte den Vorteil, dass sich Leute, die C++ bereits können, nicht erst einarbeiten müssen.

[Zepp]

Mein Fehler, im framework wird das natürlich so gemacht, zb qa_ctor.c

void QActive_ctor(QActive * const me, QStateHandler initial) {
    (...)
    QHsm_ctor(&me->super, initial);
}

Es ist sicher nicht sinnvoll irgendwelche Änderungen an QP durchzuführen. Samek wird seine Gründe haben, dass QP-C++ so aussieht wie es aussieht und im Forum auf sourceforge (ist wieder da übrigens) gibt er schnell sehr kompetent Antwort. Er wird sicher interressiert sein zu hören, dass QP als framework für den eibd in Betracht gezogen wird.

Ich habe mich nochmal umgeschaut und es gibt ja inzwischen einiges an Aktor-frameworks für C++ da sollte doch was dabei sein wenn QP nicht das richtige ist.

[Smurf]

Das Forum ist schon länger wieder da, aber das git-Repo noch nicht.

Letztlich wird die Auswahl derjenige treffen, der sich die Arbeit auf die Fahnen schreibt …

[Zepp]

Der download hier funktioniert

http://state-machine.com/downloads/index.php

[Smurf]

Danke, aber den direkten Download kenne ich schon, sonst hätte ich nicht den "me"-Parameter anmeckern können …
nur: zum Verständnis von Code ist dieVersionsgeschichte für mich sehr hilfreich. Ich fühle mich gehandicapt wenn ich die nicht habe und nachsehen kann, wie und wieso Code entstanden ist, den ich nicht auf Anhieb verstehe.

[Zepp]

Soweit ich weiß existiert das git-repo erst ein paar Monate, du wirst da wahrscheinlich nicht viel sehen.
Da sind die umfangreichen release-notes bestimmt hilfreicher.