Ich würde gern so eine Art Live-Debugging realisieren.
Dazu übertrage ich bestimmte Daten meiner Anwendung über TCP an ein lauschendes Programm.
Das funktioniert soweit.

Jetzt möchte ich das auch während dem Debuggen nutzen, bin aber nicht sicher, ob und wie das geht.


Kleines und verkürztes Gedankenexperiment:

In TForm.OnCreate läuft ein Zähler I (globale Variable) von 0 bis MaxInt hoch, mehr nicht.

Zusätzlich gibt es 3 Threads.

TThreadBeep: Beept jede Sekunde
TThreadC: Zählt einen eigenen Counter hoch und versendet den über TCP
TThreadI: Übernimmt (synchronisiert?) den Wert aus der obigen I-Schleife und versendet den.

Das sollte soweit funktionieren.
Während der Zähler hochzählt piepst die Anwendung jede Sekunde und das lauschende Programm erhält neue Werte für C und I.

Ein Breakpoint in der I-Schleife hält aber auch die 3 Threads an.

Gibt es eine Möglichkeit, diese weiter laufen zu lassen?
Ich möchte also weiter die Beeps jede Sekunde, den hochzählenden Counter C und "den aktuellen Wert aus I".
Die Threads Beep und C sollen also unbeeindruckt weiter laufen und I soll während des Debuggens immer weiter den aktuellen Wert verschicken.

Erst wenn ich mit F8 schrittweise weiter debugge, müsste also im beobachtenden Programm dann beim jeweils nächsten Schleifendurchlauf der nächste I-Wert angezeigt werden.


Lässt sich so etwas realisieren?
Ich kenne zwar die Threads im Debugfenster, weiß aber (noch) nicht, wie und wie weit man damit umgehen kann.



EDIT: Wenn das so nicht machbar ist, müsste man vermutlich einen Thread in den OTA´s verankern, aber das wäre dann mit Kanonen auf Spatzen...

Andersrum geht es definitiv.
Also man kann bestimmte Threads "blockieren", dann arbeiten sie nicht weiter, während man mit F7/F8/F9 den aktuellen/ausgewählten Thread debuggt.

Über die Open Tools API kannst bestimmt kurz nach dem Anhalten andere Threads gleich wieder starten,
aber ja, im Prinzip könnte Emba in Delphi bestimmt auch direkt zum "blockieren" noch ein "ignorieren/weiterarbeiten" einbauen, also nicht immer gleich alle Threads anhalten, wenn angehalten wird.
> Delphi hat ja beim "Weiterdebuggen" schon drin, dass nicht alle Threads wieder fortgesetzt werden, fehlt halt nur beim "Anhalten" dass nicht Alle pausieht werden.


Oder eben selbst Debugger-Anhalte-Event in der OTA suchen (und hoffen da gibt es was Passendes) und mit ResumeThread/SuspendThread rumspielen.



Ich hatte mir nur manchmal das Andere gewünscht, also dass beim Debuggen (F7/F8) die Timer blockiert/verzögert werden.

Zitat von stahli:

TThreadI: Übernimmt (synchronisiert?) den Wert aus der obigen I-Schleife und versendet den.

Also synchronisieren kannst man beim Debuggen vergessen. Das wird doch nur ausgeführt wenn der Hauptthread ProzessMessages aufruft.

Denkbar währe I durch einen Record mit Zuweisungsoperatoren (in beide Richtungen) für Integer zu ersetzen.
Der Record müsste auch eine CriticalSection enthalten, die beim Zugriff auf die interne Variable verwendet werden.

Wegen einem winzigen Integer gleich mit Kanonen auf Spatzen?

Sowas kann direkt die CPU sicher (atomar) schreiben und auslesen kann man es direkt ganz normal.
InterlockedIncrement/InterlockedExchange bzw. AtomicIncrement/AtomicExchange

Danke Euch schon mal.

Bei meiner Realanwendung laufen die Threads ja wieder los, wenn ich nach einem Breakpoint das Programm mit F9 weiter laufen lasse.
Wenn der nächste Breakpoint vielleicht nach 2-3 Sekunden erreicht würde, würde das vermutlich reichen, um einen neuen Datenbestand raus zu schicken.

Die Frage ist, wie sich das "Weiterlaufen der Anwendung" darstellt, wenn die Zeitspanne durch F8 nur einige Millisekunden beträgt.
Ob in der Zeit mal ein Thread aktiv werden kann? Vermutlich wohl nicht.
Vermutlich wäre notwendig, wie von Himitsu vorgeschlagen, dass man der IDE auftragen können müsste, bestimmte Threads nicht zu pausieren...

Dann werde ich mein Vorhaben so nicht umsetzen können...


Alternative wäre ein Debug-Viewer (ähnlich dem für TStringList), der dann die Daten dann direkt innerhalb der IDE darstellt.
Muss ich mir mal überlegen, ob ich den Aufwand betreiben will. Vom Händling her ist das ja auch nicht so optimal.

Hallo,

schon mal das neue IDE Plugin von Parnassus zum Multithreaded debuggen angeschaut?
Findet sich in GetIt package manager, könnte das evtl. können.

Einziger Nachteil: es hat wohl noch ein paar Bugs die unschöne Fehlermeldungen beim
Schließen von Projekten oder so erzeugen.

Entwickler hat aber versprochen diese zu fixen. Ist halt noch V1.00.

Grüße
TurboMagic

Vielen Dank.

Das sieht ganz gut aus, ist aber für mich vielleicht etwas zu komplex.

Ich werde doch erst mal schauen, ob ich das als internen Objekt-Viewer umsetzen kann.
Dann wäre keine Thread-Kontrolle notwendig und keine Datenübertragung über TCP.

Vielleicht ist das (wenn die benötigten Threads nicht einfach weiter laufen können) dann doch die geschicktere Lösung...


Ich gebe bescheid, ob ich das so umsetzen kann...

Alternativ ohne Thread, in deinem Code eine SendeFunktion überall einfügen/aufrufen, da kannst dann mit F8 drüber und deine Daten raussenden.

Ja, aber das ist dann unpraktisch.
Dann muss man zuvor genau sagen, an welchen Stellen man den Datenblock einsehen möchte.
Das benötigte mehrfache Korrekturen im Code und mehrfaches Debuggen und genau das will ich vermeiden.

Ich möchte also bei jedem Debug-Schritt eine aktualisierte visuelle Aufbereitung der Daten sehen.

Dafür eignen sich Tools wie TMS Logging:
https://tmssoftware.com/site/tmslogging.asp
Damit kannst du nebenbei eine Webseite aufmachen und die Logs strukturiert einsehen. Du kannst die Daten aber auch in einem eigenen IDE Plugin abrufen usw.