C-Funktionen nach C++ portieren und instanziieren
-
dot schrieb:
Evtl. ist die Variante mit mehreren Prozessen also nicht nur sauberer, sondern sogar auch noch weniger Implementierungsaufwand.
Das bezweifle ich mal stark.
Hätte aber noch andere Vorteile wenn das in verschiedenen Prozessen läuft. z.B. dass die "Systeme" dann auch wirklich weitestgehend getrennt sind, und ein Crash/krasses Fehlverhalten eines Systems (Speicher überschreiben, ...) ein anderes System nicht beeinflussen kann.
Auch könnte man einfach ausprobieren was passiert, wenn man ein System unerwartet aus dem Spiel entfernt (Taskmanager, Prozess beenden).Dafür ist es wieder lästiger in anderen Situationen. Wenn der User das Emulator-Programm beenden will, z.B. weil es sich weggehängt hat, dann muss er danach noch alle "System-Prozesse" einzeln killen. Kann man natürlich auch so machen dass die das mitbekommen und sich dann selbst beenden, aber ... auch wieder Aufwand.
-
hustbaer schrieb:
dot schrieb:
Evtl. ist die Variante mit mehreren Prozessen also nicht nur sauberer, sondern sogar auch noch weniger Implementierungsaufwand.
Das bezweifle ich mal stark.
Naja, mit dem dll-Hack muss er dann eben statt der Prozessinstanzen die einzelnen Module verwalten (abgesehen davon dass es natürlich unsauber ist, weil rumgefrickel mit temporären Dateien, der Code mehrfach gemapped wird etc.). Wenn er das prozessintern mit Threads machen will, dann muss er seinen CAN Bus immer noch selber bauen, was dann aber bedeutet er muss sich selber um die Verwaltung der Buffer und die Synchronisation kümmern. Zugegeben: Das ist jetzt auch nicht grad hochkompliziert, aber mit Pipes und separaten Prozessen braucht er all das nicht zu tun, weil es das Betriebssystem schon automatisch macht -> Nicht nur sauberer sondern auch weniger Aufwand (oder zumindest ganz sicher nicht mehr)...
-
Nein.
Da CAN ein multidrop, multi-master Bus ist, wird er soweiso etwas selbst implementieren müssen. Und wieso sollte das mit Prozessgrenze einfacher sein als ohne? Wo hilft sie mir?
Falls Sockets/Pipes wirklich hilfreich sein sollten, dann kann man diese genau so gut innerhalb eines Prozesses verwenden. Verbietet ja keiner. Abgesehen davon dass ich nicht wüsste was damit besser gehen sollte.Und je genauer er das Verhalten eines echten CAN Bus (z.B. Kollisionen/Arbitration) nachbilden will, desto eher wird er froh sein dass er keine lästige Prozessgrenze hat die bloss überall stört.
abgesehen davon dass es natürlich unsauber ist, weil rumgefrickel mit temporären Dateien, der Code mehrfach gemapped wird etc.
Sorry, aber das ist nur blah.
Dass der Code mehrfach gemappt wird ist jetzt genau 100% egal. Und seit wann ist mit Temp-Files arbeiten unsauber?
-
hustbaer schrieb:
Da CAN ein multidrop, multi-master Bus ist [...]
Das stimmt, dafür eignen sich Pipes nicht wirklich, da hast du absolut Recht.
hustbaer schrieb:
Und wieso sollte das mit Prozessgrenze einfacher sein als ohne? Wo hilft sie mir?
Nun, ich ging davon aus, dass er sowieso sowas wie Pipes oder Sockets wird verwenden wollen. In dem Fall wär die Lösung mit mehreren Prozessen auf jeden Fall ganz sicher nicht aufwändiger. Allerdings war das natürlich ein Denkfehler meinerseits.
hustbaer schrieb:
abgesehen davon dass es natürlich unsauber ist, weil rumgefrickel mit temporären Dateien, der Code mehrfach gemapped wird etc.
Sorry, aber das ist nur blah.
Dass der Code mehrfach gemappt wird ist jetzt genau 100% egal. Und seit wann ist mit Temp-Files arbeiten unsauber?Nun, dass der Code mehrfach gemapped wird ist einfach unschön, natürlich ist es jetzt kein wirkliches Problem oder so. Mir fällt jetzt auch kein rein objektives Argument gegen diese Lösung ein, wie gesagt, ich persönlich finds einfach nicht besonders "schön". Funktionieren tuts sicher...
