Zitat:
Funktioniert das Debugging denn in anderen Projekten korrekt?
Es funktioniert auch in dem selben Projekt, wenn die
VCL nicht hängt. Dann wird ganz normal die CPU Ansicht geöffnet. Es geht nur nicht, wenn die
VCL hängt.
Zitat:
Tritt das Problem nicht auf oder dauert es nur ein fünfundreißigstel so lang (und fällt deshalb nicht auf)?
Zeigt doch einfach mal den Quellcode, mit dem die UDPClients gleichzeitig getrennt werden. Hier scheint ja das Problem zu liegen. Eventuell macht der
VCL-Thread in der Zeit ja garnichts, sondern wird von Windows erst wieder an die Arbeit gelassen, wenn alle UDPClients beendet sind?
Mögliche blockierende Freigabeoperationen(?):
Socket-Cleanup bei UDP-Clients erfolgt synchron im Hauptthread?
Massenhafte Freigabe (35 Clients) blockiert die Nachrichtenverarbeitung?
Es wird einfach in einer Schleife, ein PostThreadMessage mit einer speziellen Nachrichtenkennung an die Threads geschickt, welche ja über das bekannte Konstrukt (PeekMessage) die Nachrichtenqueue ausliest und dort ein Terminate ausführt. Im Destroy des Threads, wird der
UDPClient.Active := False
zugewiesen und die Komponente freigegeben. Das wars.
Zitat:
Läuft für jeden UDPClient eine SVCHOST.exe?
Nein, sollte es denn?
Eine Sache habe ich mittlerweile rausgefunden.
Es liegt NICHT an UDP!
Ich habe im System noch viel mehr Threads und ich habe mal ein Test gemacht, andere Threads, die völlig andere Aufgaben haben, zu beenden.
Hier tritt das gleiche Problem auf. Es ist also ein grundlegendes Problem. Ich werde weiter suchen, woran das liegen könnte.
Daher nochmal meine Frage, ihr sprecht von Threadsicheren Listen und keine MessageQueue mit PeekMessage abgrasen und Events triggern. Habt ihr mal ein funktionierendes Beispiel, wie man ein Thread über so eine threadsichere Liste "Nachrichten" zukommen lassen kann und parallel dazu noch mit Events auf bestimmte Dinge triggern kann? Dann würde ich das auch gerne mal umbauen und versuchen