MainThreadHook(): Wozu wird der heute noch benötigt?

MarkusE · Oct 27th 2024

In PLUGINS.html steht:

Quote

However, sometimes a plugin may need to do something in the context of the main program thread, without being explicitly called up by the user. In such a case it can implement the function

virtual void MainThreadHook(void);

in which it can do this. This function is called for every plugin once during every cycle of VDR's main program loop, which typically happens once every second.

<b>Be very careful when using this function, and make sure you return from it as soon as possible! If you spend too much time in this function, the user interface performance will become sluggish!</b>

Display More

Ich vermute mal, vor der Verfügbarkeit von Locks musste der MainThreadHook von Plugins verwendet werden, die in einem eigenen Thread laufen und z.B. Zugriff auf die globale Timers Tabelle benötigen.

Inzwischen sind ja Locks verfügbar, und da stellt sich mir die Frage, was ein Plugin im "context of the main program thread" machen muss.

Anders gefragt: Könnte ein Plugin alles, was es in MainThreadHook macht, auch einfach in einem eigenen Thread machen? Oder gibt es Situationen, in denen ein Plugin auf den Kontext des "main program thread" angewiesen ist?

~Markus

wirbel · Oct 27th 2024

Die Frage ist, ob es überhaupt Plugins gibt, die diese Funktion benutzen.

kfb77 · Oct 27th 2024

Zumindest eines kenne ich: Das markad Plugin nutzt den MainThreadHook um daraus zur prüfen, ob gestartete markad Prozesse noch laufen, oder inzwischen fertig sind. Da dies nichts mit VDR Strukturen zu tun hat, helfen hier auch keine Locks.

MarkusE · Oct 27th 2024

live verwendet es auch. Es hat aber Nachteile, und wird in bestimmten Situationen nicht aufgerufen. Daher würde ich lieber einen eigenen Thread verwenden.

Aber: Die live Entwickler haben Kommentare wie

Quote

// may only be called from Plugin::MainThreadHook

hinzugefügt. Leider wird das nicht begründet. Daher würde ich gerne wissen, ob ich diesen Kommentar ignorieren kann (weil durch Locking inzwischen outdated). Oder ob ich mit den Nachteilen von MainThreadHook leben muss, weil die Verwendung eines eigenen Threads unerwünschte Nebenwirkungen haben kann.

kls · Oct 27th 2024

Ich hätte nichts dagegen, das loszuwerden.

Quote from kfb77

Das markad Plugin nutzt den MainThreadHook um daraus zur prüfen, ob gestartete markad Prozesse noch laufen, oder inzwischen fertig sind

Kann markad nicht selber feststellen, ob seine Prozesse fertig sind? Wozu braucht es da MainThreadHook()?

wirbel · Oct 27th 2024

Und welche Infos benötigen die Plugins, so dass sie nicht von einem extra thread laufen können?

kfb77 · Oct 27th 2024

Quote from kls

Kann markad nicht selber feststellen, ob seine Prozesse fertig sind? Wozu braucht es da MainThreadHook()?

Du fragst mich jetzt Dinge, die Jahre länger im Code drin sind, als ich mich mit markad beschäftigt habe. Und am Plugin habe ich eh fast nichts geändert.

Wenn ich mir den Code so anschaue, brauche ich Variablen aus dem Plugin (die Prozesstabelle, der gestarteten markad Prozesse). Ich muss die Tabelle ändern können, ohne mit Änderungen aus dem Plugin nach einem Recording() Aufruf (Start oder Ende einer Aufnahme) in Konflikt zu kommen. Und die Prüfung der laufenden Prozesse müsste regelmäßig aufgerufen werden. Den Aufwand, was funktionierendes zu ändern, würde ich mir gerne ersparen.

Zabrimus · Oct 27th 2024

Quote from kls

Ich hätte nichts dagegen, das loszuwerden.

Hmm.. Das web Plugin nutzt den MainThreadHook auch. Ich habe keine andere Möglichkeit gefunden festzustellen, ob der Player des Plugins abgeschaltet werden muss - z.B. durch drücken der Menu-Taste.

Es wäre ungünstig, komplett auf die Funktionalität zu verzichten.

wirbel · Oct 27th 2024

durch cStatus::Replaying evtl?

wirbel · Oct 27th 2024

btw: ich denke, dass Markus absolut recht hat, dieser hook kann den kompletten VDR unbrauchbar machen und sollte perspektivisch durch bessere Lösungen erstzt werden...

-> bald deprecated && Hilfe bei neuen Lösungen durch unser Forum..

SurfaceCleanerZ · Oct 27th 2024

Hallo,

Die gefundenen Probleme sollten schon erst mal gelöst werden, bevor man etwas streicht...

Nur meine Meinung am Rande...

MfG Stefan

MarkusE · Oct 27th 2024

Anbei der Patch für live, der den Aufruf von

Code

LiveTaskManager().DoScheduledTasks();

von MainThreadHook in einen eigenen Task verlagert. Ist jetzt nicht soo aufwändig, sollte in anderen Plugins analog machbar sein.

kfb77 · Oct 27th 2024

Wenn mein Verdacht von hier stimmt, geht es bei markad mit einem Einzeiler:

Diff

diff --git a/plugin/menu.cpp b/plugin/menu.cpp
index 7dde48ec3..2ff397d8d 100644
--- a/plugin/menu.cpp
+++ b/plugin/menu.cpp
@@ -84,6 +84,7 @@ bool cMenuMarkAd::write() {
     Clear();

     bool header=false;
+    status->Check();     // refresh list of running markad tasks
     struct sRecording *Entry=nullptr;
     status->ResetActPos();
     do {

Display More

Beim shutdown request wird eh nochmals geprüft, und dann könnte auch bei mir MainThreadHook entfallen.

kamel5 · Oct 27th 2024

skindesigner nutzt im Moment auch MainThreadHook.

Das kann ich gegebenenfalls auch anders realisieren.

Grüße

kamel5

kls · Oct 27th 2024

Wenn ich MainThreadHook() als [[deprecated]] markiere, dann bekomme ich auch in plugins.c eine Warnung, weil es ja dort benutzt wird, um es bei den Plugins aufzurufen. Gibt es eine Möglichkeit, zu sagen, "hier nicht warnen"?

kfb77 · Oct 28th 2024

Setzte die Warnings innerhalb #ifdef <irgendwas> und in plugins.c machst du vor der Stelle einen #undef <irgendwas> und danach wieder einen #define ...

FireFly · Oct 28th 2024

Für GCC gibt's wohl diesen Workaround:

Code

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
.....
#pragma GCC diagnostic pop

kls · Oct 28th 2024

Quote from kfb77

Setzte die Warnings innerhalb #ifdef <irgendwas> und in plugins.c machst du vor der Stelle einen #undef <irgendwas> und danach wieder einen #define ...

Oh mann, auf die einfachsten Dinge kommt man nicht! Danke!

Quote from FireFly

Für GCC gibt's wohl diesen Workaround:

Danke, an sowas hatte ich auch zuerst gedacht, aber der Vorschlag von kfb77 ist natürlich noch einfacher und allgemeingültig.

MarkusE Sag mir bitte bescheid, wenn ich die Funktion deprecaten soll.

MarkusE · Oct 28th 2024

> MarkusE Sag mir bitte bescheid, wenn ich die Funktion deprecaten soll.

Das ist jetzt vielleicht doch außerhalb meiner Gehaltsklasse .

Ich bedanke mich für Deine Rückmeldungen in diesem Thread. Meine Frage, ob MainThreadHook vor der Verfügbarkeit von Locks notwendig war, um auf globale Tabellen (z.B. Timers) zuzugreifen, wurde zwar nicht direkt beantwortet. Ich entnehme den Antworten aber, dass MainThreadHook zumindest jetzt nicht mehr notwendig ist.

Ich habe es aus live inzwischen ausgebaut, ein entsprechendes Update ist im git. Anmerkung: In live gab es Probleme, weil MainThreadHook während der Ausgabe einer OSD Meldung nicht aufgerufen wird.
In tvscraper wird es nicht verwendet
In dynamite wird es verwendet, um vor dem ersten Aufruf von MainThreadHook OSD Meldungen zu verhindern. Kann man vermutlich auch anders lösen.

Also, falls Du entscheidest, es auf deprecated zu setzen, baue ich es auch aus dynamite aus.

Ob die Nachteile / Probleme mit MainThreadHook so gravierend sind, dass wir allen Plugins auf's Auge drücken wollen, es auszubauen? Kann ich nicht beurteilen, Klaus, das musst Du entscheiden.

~ Markus

kls · Oct 28th 2024

Quote from MarkusE

Meine Frage, ob MainThreadHook vor der Verfügbarkeit von Locks notwendig war, um auf globale Tabellen (z.B. Timers) zuzugreifen, wurde zwar nicht direkt beantwortet.

Sorry ;-).

Quote from MarkusE

Ich entnehme den Antworten aber, dass MainThreadHook zumindest jetzt nicht mehr notwendig ist.

Sollte es zumindest nicht mehr sein.

Ich mach es dann für die nächste Version mal deprecated, dann sehen wir ja, was passiert. Mehr als eine Warnung ist es ja zunächst nicht.

MainThreadHook(): Wozu wird der heute noch benötigt?

MarkusE Oct 27th 2024

Participate now!

Share