Ja, Caching habe ich auch bei der PR schon raus gehaut. Was übrig ist sind zwei Implementationen des Interfaces „Playlist“, eines für Webstream/Einzeldateien und eines für Ordner mit.
Aber die Klasse macht noch einige anderen Dinge nebenbei, allen voran automatisches Management vom Speicher (d.h. wenn die Klasse out of scope geht, wird der allokierte Speicher automatisch freigegeben).
Die Queue mit Tiefe 1 habe ich durch eine Variable + Semaphore (+ bool für das Signalisieren) ersetzt. Theoretisch könnten ich hier auch mit einem std::atomic + bool arbeiten (std::atomic garantiert, dass zu einer Zeit nur ein Thread Zugriff auf das Objekt hat).
Hintergrund ist, dass es mir nicht möglich ist durch die FreeRTOS queues etwas anderes als ein POD (Plain Old Datatype) zu übergeben. Das schließt zum Beispiel Smart Pointer aus, die aber für das automatische Speicherverwaltung zwingen notwendig sind.
Hm, ich denke, dass ich den PR in 3 Teile teilen könnte:
Verbesserung der Generierung der Playlist
Aktuell lesen wir alle Dateipfade in einem Ordner in einen einzigen riesige String und zerteilen diesen dann in den char** array (mit dem ersten „Eintrag“ als Länge der Playlist). Nachteil hier ist neben dem hohen Speicherverbrauch bei der Generierung (Faktor 2, wir halten zu einem Zeitpunkt alle absoluten Pfade doppelt im Speicher) das manuelle Memory Management.
Umstellung von der Playlist Queue auf Atomic Variablen
Der Schritt ist notwendig um nicht nur POD pointer, sondern auch C++ Objekte Thread sicher übergeben zu können. Hier würde ich dann auch den Zugriff auf die Variablen der Playlist kapseln.
Kapselung der vorherigen Verbesserungen in Klasse(n)
Basically der nächste Schritt, Kapselung der vorherigen Verbesserungen in eine eigene Klasse.