Das Freigeben von Objekten über den Pointer einer Basisklasse ist eigentlich kein Problem. Die beteiligten Klasse sollte nur einen virtual Destruktor haben.
Posts by mini73
-
-
Es gibt zwei Gründe für steigendes Speichervolumen:
- Ein Leak, weil ein Pointer "vergessen" wird, ohne ihn freizugeben.
- Eine Datenstruktur, die immer mehr Daten sammelt und größer wird, aber kein Leak im klassischen Sinne ist, weil immer noch ein Pointer irgendwo aktiv ist und jeder Block noch bekannt ist. Das werdet ihr mit sowas wie Valgrind und Konsorten nicht finden. Da hilft nur regelmäßiges protokollieren.
Kandidaten für den zweiten Fall sind Listen usw. der Events, Schedules, Recordings, Channels...
-
Ich reagiere lieber auf Events als immer wieder zu pollen.
libjpeg, fontconfig usw. stört dich auch oder sind diese Abhängigkeiten ok? Warum sind einige Abhängigkeiten ok und andere nicht? Wofür sind solche libs denn sonst da, wenn man sie nicht genau für den Zweck nutzt, für den sie gedacht sind? In diesem Fall geht es um eine Benachrichtigung, wenn sich was an den Devices ändert.
Aber egal, wir werden uns da nie einig...
-
Es gibt DVB-Karten, die z.B. ein T- und ein S-Frontend haben, von denen aber immer nur eins exklusiv geöffnet werden kann. Wenn ich mich richtig erinnere, unterstützt der vdr das seit 2.4.1. Das zog einige Änderungen an cDvbTuner usw. nach sich, genau an den Stellen, wo der Patch auch eingreift. Ich hatte mit dem Patch schon angefangen, dann aber keine Zeit mehr, es zu Ende zu bringen.
Deshalb wird der noch nicht richtig funktionieren.
Ich weiß nicht, was die Aversion gegen udev soll. Das ist so ziemlich in jeder Distribution vertreten, es ist nichts exotisches. Und es geht nicht so sehr um das Abziehen eines usb-dvb-Sticks, der in Benutzung ist, sondern um das nachträgliche Anstöpseln eines solchen. Oder um solche Karten, die bei der Initialisierung so lange brauchen und der vdr schon lange gestartet sein könnte. Damit man keine Verrenkungen mehr machen muss, um den Start des vdr künstlich zu verzögern.
Und natürlich würde ich den Patch genauso einreichen, wie alle anderen Anpassungen, die ich gemacht habe. Und wenn Klaus das für gut befindet, hab ich Glück gehabt. Wenn nicht, dann eben nicht.
-
Der beta-Patch ist bzgl. Multi-Frontend nicht fertig. Da war bisher keine Zeit.
Ich würde das ganze Ding sowieso eher einstampfen und in einen einfachen Patch umwandeln wollen, der nur das macht, wofür dynamite eigentlich gestartet wurde: dvb-devices nach dem Start per udev erkennen und einbinden und genauso zur Laufzeit wieder aushängen können. Ich finde, das ist ein wichtiges Feature, welches dem vdr noch fehlt. Die devices sind noch viel zu statisch.
-
Weil es da schon ein paar gravierende Änderungen im Bereich der DVB-Karten mit mehreren, nicht gleichzeitig zu benutzenden Frontends gibt. Der alte dynamite-Patch passt da nicht so einfach drauf.
Und einfach nur einen diff irgendwie auflösen, dass er kompiliert, hat in meinen Augen nichts mit verantwortungsvoller Programmierung zu tun.
Der Source ist da und unter GPL, ihr dürft damit machen, was ihr wollt. Aber auf eigene Verantwortung.
wirbel einfach mal ins Readme schauen, dann kann man lesen, was es tut und entscheiden, ob man es braucht.
-
Nope
-
Die Ansible-Variante hat kein Webfrontend. Das alte lässt sich nicht einfach so auf das neue System übertragen. Ich meine, seahawk1986 arbeitet immer mal wieder dran, aber sowas dauert.
-
Wenn du das Token in einem HttpOnly-Cookie sendest, hat es den Vorteil, dass der Client sich nicht bemühen muss, das Token immer passend zu senden, weil der Browser das automatisch macht. Und bei HttpOnly kann das Javascript das Ding auch nicht abgreifen.
-
dbus2vdr hat die betroffene Funktion nicht benutzt. Es hat aber den ReadLock auf die Recordings gehalten, als es cControl::Shutdown aufgerufen hat. SVDRP gibt davor explizit den Lock frei, weil das wohl so sein muss laut Kommentar. Das macht dbus2vdr jetzt auch.
Mit vdr 2.4.2 und neuem dbus2vdr sollte es an der Stelle hoffentlich keine Probleme mehr geben. Aber das Augabeplugin kann natürlich auch noch ein verstecktes Problem haben.
-
Schön, dass ich den Staffelstab weitergeben konnte...
Mit deinem Stresstest wirst du sicherlich noch Lock-Bugs in anderen Plugins finden...
-
Ich hab das Sperren der Aufnahmeliste in dbus2vdr mal an die Variante von SVDRP im vdr angepasst. Falls es im Zusammenspiel mit dbus2vdr noch Probleme gibt, teste doch mal den Branch "playlock".
-
Evtl. hält dbus2vdr den Read-Lock auf die Recordings zu lange, das muss ich mir noch mal näher ansehen.
-
Und falls dbus2vdr doch noch blockiert, ist es vermutlich selbst schuld...
Es sieht ja danach aus, als ob cControl::Shutdown nicht zurück kommt. Wenn bei dbus2vdr Requests reinkommen, werden die meist parallel abgearbeitet. Vielleicht überholt es sich da noch etwas selbst und blockiert dann was in cControl. Ich bin da jetzt aber auch nicht mehr so stark drin im Code, da muss ich erst mal wieder lesen...
-
Sieht soweit gut aus, was das betrifft.
-
Jeder Test ist gut. Aber wenn es noch andere Änderungen gab (ich hab die Patches nicht verglichen), ist's ja gut. Ich hab den Post nur anders interpretiert.
-
Heißt das, mit dem gleichen Patch ohne Logging gibt es Probleme, mit Logging aber nicht? Das würde bedeuten, dass das Problem eigentlich noch nicht gelöst ist.
Der shared_ptr hätte den Vorteil, dass man für die Nutzung natürlich noch ein Lock bräuchte, aber keiner muss sich um ein delete kümmern, weil einfach der letzte es automatisch machen würde. Das geht natürlich nur mit "delete", nicht mit "free".
-
Ist std::shared_ptr evtl. eine Option?
-
Oder statt this evtl. control nehmen, wo es passt. Um den Pointer geht es da vermutlich.
-
Dann einfach das this=%p aus dem String weglassen und hinten den Parameter auch.
