Absturz der Anwendung nach beenden eines Threads

[himitsu]

Zitat:

Zitat von Captnemo (Beitrag 1262999)

Grad gefunden:

Siehe hatte es auch grade noch so gesehn und meinen Beitrag oben erweitert.
Vorallem das Fette und Nachfolgendes.

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1263001)

TTimer verwendet die Funktion setTimer von Windows. Du könntest das manuell versuchen.

TTimer oder ein eigenes MessageOnlyWindow+SetTimer bringt nichts, solange die "komplette" Bahandlung nicht auf einen der beiden Threads beschränkt wird.

[Captnemo]

Zitat:

Zitat von himitsu (Beitrag 1262995)

Zitat:

Delphi-Quellcode:

      self.Terminate;
      if Terminated then
      begin
        break;
      end;

Ergibt das nicht einfach nur ein

Delphi-Quellcode:

Exit;

?

Meines Wissens wir bei einem Exit die Procedure/Function verlassen, während ein Break nur die Schleife (for, while, Loop) verläßt.

Hilfeauszug:

Exit:

Zitat:

Beendet die aktuelle Prozedur.

In Delphi entzieht die Prozedur Exit der aktuellen Prozedur sofort die Steuerung. Wenn die aktuelle Prozedur das Hauptprogramm ist, bewirkt Exit die Beendigung des Programms.

Exit veranlasst die aufrufende Prozedur, mit der Anweisung nach dem Punkt fortzufahren, an dem die Prozedur aufgerufen wurde.

Anmerkung: Exit entzieht der aktuellen Prozedur die Steuerung, nicht nur dem aktuellen Block. Aber Exit verletzt den Steuerungsfluss nicht, der durch ein try..finally-Konstrukt vorgeschrieben ist; wenn Exit in der try-Klausel aufgerufen wird, wird die finally-Klausel dennoch ausgeführt.

Break:

Zitat:

Beendet eine for-, while- oder repeat-Anweisung vorzeitig.

In Delphi bewirkt Break, dass eine for, while oder repeat-Schleife verlassen und die Ausführung mit der nächsten Anweisung fortgesetzt wird.

Wird Break außerhalb einer for-, while- oder repeat-Anweisung aufgerufen, gibt der Compiler eine Fehlermeldung aus.

Anmerkung: Break wirkt sich nicht auf die Ablaufsteuerung von try..finally-Konstrukten aus. Wenn Sie Break in der try-Klausel aufrufen, wird die Ausführung in der finally-Klausel fortgesetzt.

Du hast zwar in sofern Recht, als dann der finally-Abschnitt ausgeführt wird, aber wenn man nach der Schleife noch was machen möchte, was nicht in den Finally-Abschnitt gehört, dann ist es nicht das gleiche.


Oder meintest du mein Terminate vor der Schleife?
Das war nur zu Testzwecken drin, damit sich der Thread gleich wieder beendet, und ich somit testen konnte ob irgendeine andere Procedure für den Fehler verantwortlich war.

[himitsu]

Ja, das Break verlässt die Schleife und das Exit auch.
Im Grunde wollte ich nur sagen, daß die Execute-Methode bei allen 3. Varianten verlassen (Exit sagt das nur deutlicher, zum Programmierer) und der Thread beendet wird. :angel:

Zitat:

Oder meintest du mein Terminate vor der Schleife?

Jupp, genau das.



Ob der TJvThreadTimer threadsave ist, weiß ich nicht, aber ich glaub das "Thread" im Namen sagt erstmal nur aus, wie er intern arbeitet.

TTimer geht über SetTimer und wartet auf die WM_TIMER.
Und der TJvThreadTimer erzeugt einen Thread, in dem er die Millisekunden wartet und dann das Ereignis manuell auslöst, ohne über die MessageQueue zu gehen.

[Captnemo]

Zitat:

Zitat von ensaron (Beitrag 1262989)

Hallo Captnemo,

vielleicht gibt es einen Konflikt beim Empfangen von Messages? Wenn die Messagenummer für ICS nicht explizit auf einen Startwert gesetzt wird, benutzt ICS als erste Nummer

Delphi-Quellcode:

WM_USER + 1

. Ich bin mir zwar nicht sicher, ob das zu einem Problem führen kann, aber den ICS-Messages einen Startwert zu geben, kann ja nicht schaden.
Um den Startwert zu setzen, benutze die Variable

Delphi-Quellcode:

GWndHandlerMsgLow

in der Unit

Delphi-Quellcode:

OverbyteIcsWndControl

, bevor du deine erste ICS-Komponente erzeugst.

Grüße
Thomas

Da du dich ja offensichtlich mit TWSocket schon tiefer befasst hast, noch mal eine kleine Nebenfrage.
Ich schicke zeilenweise (TCP) mit Linemode=Enabled und Lineend=#13#10.
Leider kommt aber beim Empfänger nicht immer die vollständige Zeile an. Zu 80% ist alles richtig und zwischendurch werden Zeichen "verschluckt", und zwar immer am Anfang der Zeile.
Ist der Linemode hier grundsätzlich sicher? Bzw. auf der anderen Seite das OnDataAvailable?

[mkinzler]

Zitat:

Zitat von Captnemo (Beitrag 1263006)

Da du dich ja offensichtlich mit TWSocket schon tiefer befasst hast, noch mal eine kleine Nebenfrage.
Ich schicke zeilenweise (TCP) mit Linemode=Enabled und Lineend=#13#10.
Leider kommt aber beim Empfänger nicht immer die vollständige Zeile an. Zu 80% ist alles richtig und zwischendurch werden Zeichen "verschluckt", und zwar immer am Anfang der Zeile.
Ist der Linemode hier grundsätzlich sicher? Bzw. auf der anderen Seite das OnDataAvailable?

Das wäre imho in einem eigenen Thread besser aufgehoben

[Captnemo]

Zitat:

Zitat von himitsu (Beitrag 1263005)

Und der TJvThreadTimer erzeugt einen Thread, in dem er die Millisekunden wartet und dann das Ereignis manuell auslöst, ohne über die MessageQueue zu gehen.

Das sollte doch eigentlich Threadsafe bedeuten.

Ich habe jetzt den TJvThreadTimer an Stelle des TTimer verwendet und Schwupps....alles Prima.

Ich arbeite noch nicht lange mit Threads, bzw. hatte früher nie die Notwendigkeit. Doch nun geht es nicht anders, und ich stelle langsam fest wie wichtig es ist Threadsafe zu arbeiten. Das Prinzip ist schon klar, doch bei der Umsetzung tappt man doch in so manche Falle ;)
Dank des Forums und dank euch lern ich das auch noch :-D:-D

[Captnemo]

Zitat:

Zitat von mkinzler (Beitrag 1263007)

Zitat:

Zitat von Captnemo (Beitrag 1263006)

Da du dich ja offensichtlich mit TWSocket schon tiefer befasst hast, noch mal eine kleine Nebenfrage.
Ich schicke zeilenweise (TCP) mit Linemode=Enabled und Lineend=#13#10.
Leider kommt aber beim Empfänger nicht immer die vollständige Zeile an. Zu 80% ist alles richtig und zwischendurch werden Zeichen "verschluckt", und zwar immer am Anfang der Zeile.
Ist der Linemode hier grundsätzlich sicher? Bzw. auf der anderen Seite das OnDataAvailable?

Das wäre imho in einem eigenen Thread besser aufgehoben

Du meinst so:

Im TCP-Server im OnSessionAvailable die neue Session im Thread erzeugen und dort im OnDataAvailable alle ankommen in einen Messegebuffer vom Mainthread, und dort verarbeiten?

[mkinzler]

Nein in einem eigenen Beitrag hier im Forum!

[himitsu]

Zitat:

Zitat von Captnemo (Beitrag 1263010)

Das sollte doch eigentlich Threadsafe bedeuten.

Njain.

Ich sag mal so:
Du hast eine Komponente erstellt
und nur weil sie ein einem anderem Thread verwendet wird, ist sie damit nicht automatisch threadsave. :zwinker:

Das kommt dann drauf an, wie die Steuerung arbeitet und ob sie eventuell entsprechend abgesichert ist, also vorallem dein Setzen des Intervalls oder des Enable.
Das Free dagegen rufe man ja eh fast immer aus einem anderem Thread auf, womit es da weniger Probleme gibt. Aber vermutlich werden die das wohl bedacht haben.

Und dann kommt es auch noch darauf an, ob die das Timer-Event synchronisieren. (wobei ich das jetzt nicht glaub, da der Timer dann ja ungenauer laufen würde)