Win64 VCL Applikation Delphi 11.3 - not respondig

[Uwe Raabe]

Zitat von taveuni:

dass z.B. TWinControl.Handle Getter nicht Threadsafe sind. Deshalb habe ich auch die synchronsiert bzw. in Variablen gespeichert.

Das wird vermutlich nicht reichen. Der Zugriff auf VCL-Controls aus einem Thread heraus ist eben nicht thread-safe. Selbst wenn man ein solches Handle synchronisiert erhält, bedeutet das nicht, dass es beim nächsten Mal auch noch gültig ist. VCL-Controls erzeugen immer mal wieder ihr Handle neu.

Solange die Controls permanent vorhanden sind, kann man Referenzen auf diese verwenden um die entsprechenden Aktionen synchronisiert auszuführen. Innerhalb dieser Aktion kann man auch das Handle verwenden, solange man sicher ist dass es während der Aktion nicht durch irgendwas neu erzeugt wird. Im Zweifelsfall an jeder Stelle das Handle Property verwenden und nicht irgendwo zwischenspeichern.

[taveuni]

Zitat von Uwe Raabe:

Das wird vermutlich nicht reichen. Der Zugriff auf VCL-Controls aus einem Thread heraus ist eben nicht thread-safe. Selbst wenn man ein solches Handle synchronisiert erhält, bedeutet das nicht, dass es beim nächsten Mal auch noch gültig ist. VCL-Controls erzeugen immer mal wieder ihr Handle neu.

Solange die Controls permanent vorhanden sind, kann man Referenzen auf diese verwenden um die entsprechenden Aktionen synchronisiert auszuführen. Innerhalb dieser Aktion kann man auch das Handle verwenden, solange man sicher ist dass es während der Aktion nicht durch irgendwas neu erzeugt wird. Im Zweifelsfall an jeder Stelle das Handle Property verwenden und nicht irgendwo zwischenspeichern.

Ich bin mir nicht sicher ob ich Dich richtig verstehen. Die GUI besteht aus einzelnen "Playern" welche diese Panels, die Verbindungsscreens usw. kapseln. Diese werden auch dynamisch freigegeben und erzeugt. Wenn z. B. ein Player via API versucht eine Verbindung zu erzeugen welche nicht vorhanden ist und vor dem Timeout für diesen Player eine neue Aufschaltung kommt wird der bestehende freigegeben und ein neuer erzeugt.
Beim ersten synchronisierten Aufruf dieses Players wird dann das Panel.Handle sicher ermittelt und einer Klassenvariable gespeichert. Folgend wird immer diese Variable mit einem Getter der Klasse mit TCriticalSection abgesichert geholt und der API übergeben. Ist das so gemeint von Dir?

[taveuni]

Zitat von Uwe Raabe:

Im Zweifelsfall an jeder Stelle das Handle Property verwenden und nicht irgendwo zwischenspeichern.

Was aber wenn ich das Handle benötige um mit PostMessage aus einem Thread heraus zu notifizieren? Vermulich ist das dann sowieso der falsche Ansatz und ich sollte für dies wieder zu Events zurückkehren. Und dies mit TThread.Synchronize tun. Dann bin ich diesbezüglich aber wieder am Anfang.

[Kas Ob.]

@taveuni , hi

Sorry for "My bad is English" and the translation, so i might missed many stuff.

But i did few projects with security cameras and recording/handling images software, and want to points few things that can be problem for you to face:

1) The most important thing is to have small code to test the limit of decoding, this code should be portable and included within the software, i mean yes you have hardware (GPU) decoding but there is limit of how many streams can be decoded concurrently, GPU tend to throttle instantly.
2) Crucial thing to do is to not allow or implement any sort of inter-threads communication, i mean 0 interaction between threads them selves or with the main threads, this make no sense at first but will i will explain it further down.
3) the drawing form the main thread should not perform more than fixed frame per second, and definitely should not wait on the background decoding threads, and will not have (or wait for) any notification from them.
4) logging should be lock free.

Now to some details :
GPU decoding can be overwhelmed easily and will stop/slow for each and every stream, so should be throttled, hence the test and benchmark, also after feeding the stream and when you want to decode to different one, make sure to flush the stop decoding for the ones that is not needed, if the application is to save the encoded streams then let them continue to just save only.
The decoding threads will have the decoded images in a ring buffer, lock free would be perfect but any will do, and will not perform any notify for that matter, just drop the image in bucket or list or whatever....
Drawing from the main thread should be happen with a timer, simple as that, remove the images from the buffers then draw then recycle, try to recycle (cache) these Bitmaps, again with lock free list.
That timer must not be more frequent than the Hz of the monitor and the FPS from these streams.
Mainthread will draw/render all the images, if there were new images or not, it will just consume what in the filled buffer from each decoding threads.

Your decoding DLL might provide two method of decoding synchronous and/or asynchronous, use the synchronous (blocking) one.

As a rule of thumb stay away from sending/posting messages, the interthread communication should be limited to go and stop, and may be , i say be a counter for decoded images, and that is it.

After building that you can go fancy and add features, like watermarks special editing, motion detection ...

Hope that helps.

[Uwe Raabe]

Zitat von taveuni:

Was aber wenn ich das Handle benötige um mit PostMessage aus einem Thread heraus zu notifizieren?

Was aber, wenn das Handle durch ein RecreateWnd neu erzeugt wird? Das kann auch bei einem Control in der Parentfolge des Panels sein, was dann auch das Handle des Panels unbrauchbar macht.

Das Problem besteht übrigens unabhängig von Threads.

[himitsu]

Passiert auch, wenn man StayOnTop ändert
oder wenn ein Fenster minimiert ist und aus Platzspargründen vorübergehend aus dem Speicher fliegt.

Für sowas sollte man sich in eines der entsprechenden Methoden einhängen

Delphi-Quellcode:

    procedure CreateWindowHandle(const Params: TCreateParams); virtual;
    procedure CreateWnd; virtual;

    procedure DestroyHandle; virtual;
    procedure DestroyWindowHandle; virtual;
    procedure DestroyWnd; virtual;

bzw. WM_CREATE, WM_DESTORY, CM_RECREATEWND usw.


z.B. bloß im Constructor eine Funktion am Handle (HWND) zu aktivieren und sich dann zu wundern, wenn sie zur Laufzeit irgendwann mal weg ist ... schon bissl unpraktisch.

[taveuni]

Ich bin jetzt 4 Tage nicht im Büro. Werde mich am Dienstag wieder damit beschäftigen. Allgemein: was kann den Hauptthread lahmlegen ohne dass dieser beschäftigt ist?

[himitsu]

ein Deadlock ... Sleep, WaitFor oder I/O, wo der Treiber auf was wartet, usw.

Wenn es lang genug hängt, im Debugger auf Pause und schauen wo der Thread grade hängt (Stack).

[taveuni]

Zitat von himitsu:

ein Deadlock ... Sleep, WaitFor oder I/O, wo der Treiber auf was wartet, usw.

Wenn es lang genug hängt, im Debugger auf Pause und schauen wo der Thread grade hängt (Stack).

Da fehlt mir leider das Verständnis. Als ich mich mit dem remote debugger eingehängt hatte war ja irgendwie pausieren nach Verbindung angehakt. Da würde ich dann etwas sehen?
Ich komme gerne darauf zurück.