TIdTCPServer (Indy) und TClientSocket

[Bambini]

Zitat von Schwedenbitter:

Das isz jetzt zwar OT: aber wenn ich das richtig deute, muss ich dann auch VCL-Zugriffe in allen TIdTCPServer-Ereignissen entsprechend absichern? Das ist ein ganz schöner Overhead, finde ich.
Ich vermisse dann auch einen Compiler-Hinweis. Der "liest" ja den Code und sollte das wissen

Wer welchen Code zur Laufzeit aufruft, kann der Compiler nicht sehen und daher nicht helfen.

Zitat von Schwedenbitter:

Ich habe in meinem Thread das Ereignis aus dem Thread heraus threadsicher (hoffe ich) aufgerufen. Warum machen das die Indys nicht gleich so? Und was mache ich, wenn die Prozeduren größer als eine klitzekleine Ausgabe in der GUI werden? ...

Das bremst die Clients nebeneinander aus. Wenn Client1 in OnExecute() einen größeren Job zu erledigen hat, dann kann kein weiterer Client etwas machen.
Daher ist es schon sehr gut, dass die für jeden Client im eigenen Thread läuft.

Zitat von Schwedenbitter:

Zitat von Bambini:

Ich will nur sagen, dass das OnExecute() from TidTCPIPServer von einem Thread aus gerufen wird. Das macht die Komponente schon ganz alleine. Jedoch muss man dann aufpassen, das deine Code dann Threadsicher ist. D.h. Zugriffe auf Globale Variablen und UI sind zu synchronisieren (s.o.)

Aber dass das Ereignis aus einem Thread aufgerufen wird, macht es doch nicht automatisch threadunsicher, wenn es sauber programmiert wurde. Ich dachte immer, so wäre es richtig und alle schlauen Ersteller von Komponenten würden das so (richtig) machen:

Delphi-Quellcode:

// Völlig ungetestet zusammengeschrieben, um die Frage zu verdeutlichen!!!
type
   TfoobarEvent   = procedure (Value: Integer) of object;

   foobar = class(TThread)
   private
      FValue      : Integer;
      FOnErgebnis   : TfoobarEvent
      Procedure FireThreadSafe;
   protected
      procedure Execute; override;
   public
      property OnErgebnis: TfoobarEvent read FOnErgebnis write FOnErgebnis;
   end;

implementation

procedure foobar.FireThreadSafe;
Begin
   if Assigned(FOnErgebnis) then FOnErgebnis(FValue);
End;

procedure foobar.Execute;
begin
   while not Terminated do
   begin
      FValue:= Random(5000);
      if (FValue = 0) then Synchronize(FireThreadSafe);
   end;
end;

In diesem Fall muss ich dann innerhalb des VCL-Teils kein Syncronize mehr benutzen, oder doch?
Ich bin jetzt etwas verwirrt.

Nein muss du dann nicht mehr. Einmal Synchronize reicht.

[Schwedenbitter]

Zitat von Bambini:

Wer welchen Code zur Laufzeit aufruft, kann der Compiler nicht sehen und daher nicht helfen.

Das ist richtig. Aber wenn ich z.B. einem String einen AnsiString zuweise oder umgekehrt, bekomme ich ja auch wenigstens eine Warnung - unabhängig davon, dass er das "durchcompiliert". Aber das führt auch zu weit.

Kannst Du mir bitte einen Gefallen tun:
Du schriebst weiter oben, dass bei Dir das Ereignis auch ohne #13#10 ausgelöst wird. Bei mir eben nicht. Am Quellcode kann es also (theoretisch) nicht liegen.
Macht es Dir was aus, mit ggf. per PN oder so eine von Dir compilierte exe-Datei zuzusenden?

Gruß, Alex

[Bambini]

Zitat von Schwedenbitter:

Du schriebst weiter oben, dass bei Dir das Ereignis auch ohne #13#10 ausgelöst wird. Bei mir eben nicht. Am Quellcode kann es also (theoretisch) nicht liegen.
Macht es Dir was aus, mit ggf. per PN oder so eine von Dir compilierte exe-Datei zuzusenden?

An einer EXE wirst du es aber nicht sehen können. Das OnExecute() wird zwar gerufen, aber an dem ReadLn() kommt er nicht vorbei.
Von "Außen" sieht man das nicht. Nur wenn du einen BreakPoint in das OnExecute beim begin setzt, also VOR dem ReadLn() und deinen String ohne CRLF schickt, solltest du es auch sehen.

[Schwedenbitter]

Zitat von Bambini:

An einer EXE wirst du es aber nicht sehen können. Das OnExecute() wird zwar gerufen, aber an dem ReadLn() kommt er nicht vorbei.
Von "Außen" sieht man das nicht. Nur wenn du einen BreakPoint in das OnExecute beim begin setzt, also VOR dem ReadLn() und deinen String ohne CRLF schickt, solltest du es auch sehen.

Entschuldige bitte. Ich weiß, dass ich langsam wohl nerve. Aber ich muss nochmal fragen.
OnExecute wird aufgerufen. Warum sehe ich dann wiederum keine Meldung; auch wenn ich die Ausgabe ganz an den Anfgang setze:

Delphi-Quellcode:

Procedure TForm1.IdTCPServerExecute(AContext: TIdContext);
Var
   Data:String;
Begin
   ScrollLog('OnExecute();');
   Application.ProcessMessages;

   Data:= AContext.Connection.Socket.ReadLn();
   Data:= Trim(Data);   // Sonder- und Leerzeichen entfernen
   TThread.Synchronize(nil,   // threadsicherer VCL-Zugriff
      Procedure()
      Begin
         ScrollLog('[Srv]: received:');
         ScrollLog('=> ' + Data);
      End);
End;

[Bambini]

Zitat von Schwedenbitter:

Aber ich muss nochmal fragen.
OnExecute wird aufgerufen. Warum sehe ich dann wiederum keine Meldung; auch wenn ich die Ausgabe ganz an den Anfgang setze:

Delphi-Quellcode:

Procedure TForm1.IdTCPServerExecute(AContext: TIdContext);
Var
   Data:String;
Begin
   ScrollLog('OnExecute();');
   Application.ProcessMessages;

   Data:= AContext.Connection.Socket.ReadLn(); //<--- Das wartet ewig, bis da etwas kommt
   Data:= Trim(Data);   // Sonder- und Leerzeichen entfernen
   TThread.Synchronize(nil,   // threadsicherer VCL-Zugriff
      Procedure()
      Begin
         ScrollLog('[Srv]: received:');
         ScrollLog('=> ' + Data);
      End);
End;

Das OnExecute() wird von jedem IndyThread gerufen und zwar alle Nase lang, wenn du da nix machst, kommt der sofort wieder.
Und das macht jeder Thread pro Connection, egal ob da etwas auf der Leitung angekommen ist oder nicht.
Mit ReadLn legst du den schlafen, bis ReadLn etwas zurück liefert.

PS: mit  if AContext.Connection.Socket.Readable() then begin kannst abfragen, ob da etwas zum lesen gibt.

[stahli]

Ich denke (hoffe), dass folgendes zutrifft:


TForm1.IdTCPServerExecute(...) ist eine Ereignisbehandlung.

TForm1.KeyPress(...) auch.

KeyPress wird vom Mainthread selbst ausgelöst, wenn von Windows eine Message TasteGedrückt ansteht.
KeyPress läuft also innerhalb des Mainthreads und ist somit (Main-)Threadsafe.

IdTCPServerExecute wird jedoch von einem aus Indy erzeugten Thread heraus aufgerufen - also nicht aus dem Mainthread heraus.
Wenn dort irgendwelche Schweinereien gemacht werden, die den Mainthread bzw. das Formular berühren, dann kann das zu Problemen führen.

Innerhalb eines Thread-Kontextes sollte man nie Application.ProcessMessages und nie ShowMessages o.ä. aufrufen.
Aufrufe, die den Mainthread berühren müssen über Synchronize aufgerufen werden, damit es keine Zugriffskonflikte mit dem Mainthread gibt.

2 Threads, die da weiterhelfen können:
http://www.delphipraxis.net/190294-p...alsection.html
http://www.delphipraxis.net/190675-c...mziehen-2.html

[Bambini]

Zitat von Schwedenbitter:

Das ist richtig. Aber wenn ich z.B. einem String einen AnsiString zuweise oder umgekehrt, bekomme ich ja auch wenigstens eine Warnung - unabhängig davon, dass er das "durchcompiliert". Aber das führt auch zu weit.

Der "Code" ist problemlos, der parallele Zugriff ist die Kunst dabei. Und Windows Controls, wie z.B. das TMemo, nehmen es einem recht schnell übel, wenn ein anderer Thread sich mit denen unterhalten will.