Ursache für hängende Applikation herausfinden

[jaenicke]

Du rufst Application.ProcessMessages im Threadkontext auf und greifst damit ganz tief in die Messagebehandlung der VCL ein. Das kann nicht klappen.

In einer länger laufenden Methode, die im Hauptthread läuft, wird das verwendet, damit die GUI noch reagiert, indem dort die Paint-, Maus- und Tastaturmessages abgearbeitet werden. (Besser ist natürlich, das zu vermeiden.)

In einem Thread ist das nicht nötig (und auch nicht möglich). Wenn du warten möchtest, rufst du einfach Sleep auf. Da der Thread separat läuft, blockierst du damit auch nicht die GUI. Oder du wartest auf ein Event eine definierte Zeit.

[Bodenseematze]

Hmm, auch wenn ich die Stelle Application.ProcessMessages() im Code mit Sleep(0) oder Windows.Yield() austausche,
bleibt das ganze (wie gewohnt ) hängen...

Daran kann es also nicht (nur) liegen...

[Kas Ob.]

Zitat von Bodenseematze:

Hmm, auch wenn ich die Stelle Application.ProcessMessages() im Code mit Sleep(0) oder Windows.Yield() austausche,
bleibt das ganze (wie gewohnt ) hängen...

Daran kann es also nicht (nur) liegen...

Remove Synchronize, redesign it without Synchronize.

[peterbelow]

Zitat von Bodenseematze:

Hmm, auch wenn ich die Stelle Application.ProcessMessages() im Code mit Sleep(0) oder Windows.Yield() austausche,
bleibt das ganze (wie gewohnt ) hängen...

Daran kann es also nicht (nur) liegen...

Nur noch was am Rande: MsgWait.. macht innerhalb eines sekundären Threads keinen Sinn da ein solcher Thread keine message queue hat! Er wird also niemals eine input-message (QS_ALLINPUT) bekommen, alle vom Benutzer generierten Messages (mouse, keyboard) landen in der Queue des main threads und der sekundäre thread sieht sie nicht.

[Bodenseematze]

Zitat von jaenicke:

Der Aufruf passierte laut Stacktrace 67 Zeilen weiter unten ab dem begin des Execute gezählt. Da ist im geposteten Quelltext ein end. Da müsstest du noch einmal schauen, was dort vorher stand.

Im geposteten Quellcode wurden die Aufrufe für mein Logging entfernt - deswegen die Diskrepanz.

Das wäre dann die Zeile

Delphi-Quellcode:

                        // Methode direkt aufrufen:
                        try
-->                           _evTimerFunc( Self );
                        except

Zitat von jaenicke:

Und wenn nun ohne ProcessMessages die Anwendung hängt... sieht der Bugreport noch genauso aus? Dein Timer nutzt ja nicht immer Synchronize. Kann es vorkommen, dass es ohne aufgrufen wird und dort etwas mit der VCL passiert?

es ist auch aktuell die o.a. Zeile...

Zitat von jaenicke:

Nicht die Statusanzeige oder deren Steuerung gehören in den Thread sondern die lange dauernden Aktionen selbst.

Da gebe ich Dir prinzipiell schon recht, aber das ist auch nicht so einfach.
Da werden externe Prozesse gestartet, Dateien mehrmals hin und her kopiert und angepasst, Reportdaten aktualisiert, eine Paradox-Tabelle mit Daten befüllt und andere Dinge...
...der Ablauf war ursprünglich nicht so aufwändig - es ist aber mit der Zeit immer mehr geworden und jetzt merkt man eben, dass es eine deutlich Verzögerung im Ablauf gibt.

Deswegen der Gedanke mit dem "Bitte warten..."-Dialog, in dem auch die aktuell ausgeführte Aktion textuell angezeigt werden soll.
Da in der ursprünglichen Version der angezeigte Text nicht aktualisiert wurde (bzw. die Aktualisierung nicht angezeigt wurde, hatte ich den Gedanken mit dem Thread, der den Text im Dialog animiert und refresht.

Zitat von jaenicke:

Wenn du im Hauptthread eine Aktion ausführst, kann auch ein Thread keine Aktualisierung der GUI durchführen. Dann bleibt Synchronize schlicht hängen, weil Synchronize voraussetzt, dass der Hauptthread auch funktionsfähig ist, sprich Nachrichten abarbeitet. Das Synchronize wird in WM_IDLE abgearbeitet. Wenn der Hauptthread beschäfitgt ist, passiert das nicht.

Das würde erklären, warum die Dialoganzeige nicht aktualisiert wird...

Zitat von jaenicke:

Alternativ (aber nicht so schön) könntest du auch ein threadbasiertes Fenster anzeigen. Das kann auch direkt aus dem Thread ohne Synchonisierung verwendet werden.

Wenn es da einen "einfachen" Dialog gäbe, dessen Text selber aktualisiert, wäre das nicht schlecht!

Zitat von jaenicke:

https://github.com/jaenicke/MTCL
Da es dafür mittlerweile doch Interesse gibt, arbeite ich daran vielleicht doch mal weiter...

Ich schaue mir die mal an, vielleicht kann ich da was raus extrahieren...

Zitat von peterbelow:

Nur noch was am Rande: MsgWait.. macht innerhalb eines sekundären Threads keinen Sinn da ein solcher Thread keine message queue hat! Er wird also niemals eine input-message (QS_ALLINPUT) bekommen, alle vom Benutzer generierten Messages (mouse, keyboard) landen in der Queue des main threads und der sekundäre thread sieht sie nicht.

Ich sehe schon, ich werde diese Klasse komplett wegschmeissen müssen - die macht so keinen Sinn...

Zitat von Kas Ob.:

Now to this whole big thread, it is way more complex than it should be.

Thanks a lot for your help / suggestions.
But I'm not sure if I understand everything you mentioned.
Maybe you have some example code for it?

So actually I need a dialog who shows some progress messages - the thread should be able to set the text on that dialog (or the whole dialog is the thread) to show the progress even when the main thread is busy...

EDIT: BTW, the dialog itself could also be a generated native windows dialog - it must not be Delphi at all

[TiGü]

Der ganze Ansatz ist schon komplett für die Füße.
Du musst deine komplexen und langen Operationen in Tasks/Threads packen und die geben zwischendrin oder am Ende Bescheid, was Sachlage ist.

[jaenicke]

Zitat von Bodenseematze:

Da gebe ich Dir prinzipiell schon recht, aber das ist auch nicht so einfach.
Da werden externe Prozesse gestartet, Dateien mehrmals hin und her kopiert und angepasst, Reportdaten aktualisiert, eine Paradox-Tabelle mit Daten befüllt und andere Dinge...

Wenn du da nicht ran möchtest, bleibt dir nur der Weg über ein Fenster, das außerhalb des Hauptthreads läuft. Da sollte die MTCL in der aktuellen Form schon reichen. Eine Textanzeige und eine ProgressBar hat sie drin.

[Kas Ob.]

Zitat von Bodenseematze:

the thread should be able to set the text on that dialog

That is the problem !

Don't push the info (or data) from background thread to main thread or GUI (VCL), let the VCL/GUI poll the status from the threads, but if it is necessary then notify by (well highly recommended) a message, also make the thread limit its notification to time based condition, like lets say we are moving/copying a folder, if that folder have 10k of small files, it makes no sense to notify or update the UI for each of them, right !?, the copying thread will notify once every 1/10 or 1/20 of second and when finished, and that it is, or will not notify anyone/anything, thread is doing his job and updating single place with data, UI will update with timer, here if the OS itself is way overwhelmed with other application or the CPU is very slow, the application and its UI will not block and will not fail beyond what the OS allow it, but will recover nicely when CPU (hardware in general) is relaxed.

A modal form can block the VCL/GUI/UI.. and show "please wait.." or "working...", while have a timer to get the current status/operation form the worker threads, here you don't need to time your background threads or their operation, they just updating a list (may be a list, or properties ... whatever) in thread safe way, while your dialog or modal form will have a timer and update.

one problem though if the thread operation might take long time and can't be cut or sliced in shorter job, (as example coping 8GB file on SSD or HDD) then nothing can be sliced and here you need to switch to overlapped file operation, https://learn.microsoft.com/en-us/wi...put-and-output

Also look at this nice answers https://stackoverflow.com/questions/...fast-file-copy

Notice also these are not utilizing the overlapped IO, yet these operation (reading/writing) can have it and you can have timeout on any of these operation, also as in the second answer 512KB buffer while the first will be very slow with 1KB, i would suggest to try to perform a read with less than 64KB on any modern hardware to not waste time, and 512KB sound good too with modern hardware cache buffers, in all cases if one of these operation will block for long time then you need to switch to overlapped and use them exactly as sockets !, you call the operation with overlapped structure having an event then poll on that event, in such design you can cancel the operation any time.

The code above can be adjusted to run in background thread and store the current filename(, size, position...etc) inside the thread itself, while your gui with a timer will update the status.

I keep telling that : you should not push form a background thread to main, because i saw this many times, code working perfectly for years, here comes new faster and powerful hardware makes things light speed for UI to keep up, that working code in the past is overwhelming the UI, that happened not because the developer was short sighted, but hardware changed and evolved, few months back i fixed a code (not mine but been asked to modernize it) was working for ages, now it fail with unexpected behavior because the client (owner of that legacy software) started to use hardware with SSD and 2.5Gbs connection, in the past it was on HDD and ADSL.

Hope that helps.

[jaenicke]

You are right, but those optimization details do not match the problem. The problem is, that the main thread is blocked. So a timer won't work better.

As I wrote there are only two possibilities:
- A bigger refactoring, which includes moving the long running operations to a background thread. Of course this can be a really big task.
- Or using a status window, which runs in its own thread, so it can be displayed and updated even when the main thread is fully blocked (as I do it with my MTCL). This is a simple and quick solution (which of course does not solve the design flaws).

[Bodenseematze]

Auch wenn es wieder eine Weile her ist - ich wollte noch kurz berichten, was ich jetzt schlussendlich unternommen habe...

Zitat von jaenicke:

As I wrote there are only two possibilities:
- A bigger refactoring, which includes moving the long running operations to a background thread. Of course this can be a really big task.
- Or using a status window, which runs in its own thread, so it can be displayed and updated even when the main thread is fully blocked (as I do it with my MTCL). This is a simple and quick solution (which of course does not solve the design flaws).

Und ich habe die dritte Möglichkeit gewählt

Ich habe das Fenster komplett eliminiert und mir die einzelnen durchgeführten Arbeitsschritte, die so lange gedauert haben, genauer angeschaut.
Das habe ich dann optimiert und teilweise auch auf den Datenbankserver verlagert.
Dadurch hat sich die Laufzeit des Codes drastisch reduziert - es ist zwar immer noch keine "Nullzeit", aber zumindest soweit erträglich, dass ich kein "Wartefenster" und auch kein riesiges Refactoring mehr brauche...