Warum innerhalb eines Threads Application.ProcessMessages; ?

ohne Application.ProcessMessages in der Sleep-Methode blockt meine anwendung. warum weiß ich nicht. <- quatsch.

habe die procedure nun so geändert dass über eine boolsche variable geprüft wird ob man ProcessMessages braucht oder nicht.
wenn der aufruf aus einem thread kommt > nein, sonst > ja.

bisher gibt es aber keinen unterschied bezüglich cpu last.

Zitat von d7user1:

ich pausiere das mit einem while pausiert do LongDelay(25); .
die prozessorauslastung bleibt aber konstant auf dem vorherigen wert und sinkt nicht auf 0.

Was spricht denn dagegen einfach ein Sleep(25) zu verwenden? In einem Thread, der momentan mangels Aufgabe in einem 'Pause' Zustand ist, wird ein Sleep(25) keine negativen Auswirkungen auf die Programmausführung haben, auch nicht für den VCL Thread.

also ein sleep(25) funktioniert im thread. aber im vcl-thread blockt es mir das ganze programm.

Wenn du eine Single Core CPU hast und dein Thread viel zu tun hat, spricht aber auch gar nichts dagegen, dass der 100% CPU Last erzeugt. Warum sollte die Aufgabe des Threads denn auch unnötig lange brauchen?

Im Process Explorer kannst du auch schauen welcher Thread überhaupt die Auslastung verursacht.

Zitat von d7user1:

also ein sleep(25) funktioniert im thread. aber im vcl-thread blockt es mir das ganze programm.

Sleep im VCL-Thread blockiert natürlich das Programm. Aber worauf bzw. warum soll denn im VCL-Thread 25 Millisekunden gewartet werden? Wie sieht die Warte-Funktion (LongDelay) jetzt aus?

Wenn im Hauptthread nichts gemacht wird (also keine Messages anstehen),
dann ist diese Schleife ständig nur mit Nachsehen beschäftigt, ob es jetzt was gibt und lastet dann mit Nichts den Kern/Thread zu 100% aus.

PS: Selbst ein Sleep(0) kann etwas ausrichten.
Jeder Thread bekommt ja bom Sheduler immer paar Millisekunden zum Arbeiten, bis die anderen Threads auch mal etwas Zeit bekommen. Und Sleep(0) gibt die Restzeit sofort ans Windows zurück.

Wenn ich mir die Execute-Methode da ansehe (von den bösen Zugriffen auf die VCL abgesehen), wundert mich da nichts.

Würde man die Execute-Methode in den Mainthread verlagern und so laufen lassen, wäre die CPU-Last 100%. Warum sollte das also in einem Thread anders sein ? Es ist ein Trugschluß zu glauben, man verlagere seinen Programmcode einfach in einen Thread und *poff*, geht meine CPU-Last auf Null

Ein volles Rohr in einer Endlosschleife laufendes Programm belegt eben auch die komplette Zeit die CPU - egal ob nun im Mainthread oder als Nebenthread. Erst, wenn Pausen ins Spiel kommen (zum Beispiel "nur alle 250ms eine Runde durchs TreeView"), geht die Last auch zurück.

Zitat von OlafSt:

Wenn ich mir die Execute-Methode da ansehe

Nicht verwechseln. d7user1 ist nicht der Fragesteller von damals.
Aber solche Missverständnisse sind vorprogrammiert, wenn man einen alten Thread kapert statt einen eigenen aufzumachen.