Autor Beitrag
Sqall
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 30



BeitragVerfasst: Mo 27.12.04 13:45 
Also, um es so auszudrücken hab ich jetzt nen chat programm geschrieben. Hab mir die eventhandler von dem TcpServer und TcpClient angeguckt. mein problem ist das ich es jetzt so gelöst habe das sich der client nach jedem schicken seiner texte wieder disconnected damit cih beim server OnAccept benutzen kann. Das ist aber sehr doof und macht sehr viele probleme wenn der server gar nciht existiert und du dann lines schickst. Das kann trotz überprüfung ob der server existiert sehr lange warte zeiten beanspruchen. Deshalb ist meine frage ob es einen eventhandler gibt der reagiert wenn etwas ankommt und dann darauf die empfangenen daten in ein memo packt. Wäre ja nciht weiter schwer. Aber ich hab noch keinen gefunden. Falls es sowas nciht gibt einfach schreiben und ich überlege mir was anderes. keiner soll mir eine andere methode verraten. Das wäre dann ja langweilig es zu schreiben. Ne andere Idee wäre es mit nem timer zu machen, der alle paar milisekunden überprüft ob was angekommen ist. Das wäre aber schlecht und auch sehr ungenau.

mfg

Sqall
Grendel
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 443

Gentoo Linux, MacOS X, Win 2000
D5 Ent, D7 Ent, Lazarus, Anjuta, MonoDevelop
BeitragVerfasst: Mo 27.12.04 14:16 
Moin, moin!

Du bekommst beim "OnAcceppt()" des Servers doch einen "TCustomIpClient" übergeben. Und der hat auch ein OnReceive().
Der Server erzeugt für jede neue Verbindung ein solches Object um die einzelnen Verbindungen auseinander halten zu können. Würden die OnReceive Events direkt auf dem Server liegen wüsstest Du ja nie von welchem Client es ausgelöst wurde.

Bis neulich ...
Udontknow
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2596

Win7
D2006 WIN32, .NET (C#)
BeitragVerfasst: Mo 27.12.04 15:29 
Hallo!

Grendel hat folgendes geschrieben:

Der Server erzeugt für jede neue Verbindung ein solches Object um die einzelnen Verbindungen auseinander halten zu können. Würden die OnReceive Events direkt auf dem Server liegen wüsstest Du ja nie von welchem Client es ausgelöst wurde.

Wofür gibt es denn Parameter? :wink:

@Sqall:
Wenn du Indy installiert hast, kannst du dir ja mal die SimpleTCP-Komponenten in der Open-Source-Units-Sparte ankucken.

Cu,
Udontknow
Grendel
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 443

Gentoo Linux, MacOS X, Win 2000
D5 Ent, D7 Ent, Lazarus, Anjuta, MonoDevelop
BeitragVerfasst: Mo 27.12.04 15:44 
Udontknow hat folgendes geschrieben:
Wofür gibt es denn Parameter?

Sag Du es mir.
Ob ich nun ein Connection Objekt als Parameter des Events vom Server übergebe oder ob ich das Event direkt auf dem Objekt auslöse scheint tatsächlich erstmal egal. (Wobei der zweite Weg aus OO Sicht schon eleganter wäre) Sobald man aber mehrere Verbindungen in Threads verwalten will ist das Event am Server schon wieder sehr ungünstig, da man laufend per Synchronize() seine Threads ausbremsen muss.

Bis neulich ...
Udontknow
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2596

Win7
D2006 WIN32, .NET (C#)
BeitragVerfasst: Mo 27.12.04 15:57 
Ahso, mißverstanden. Deine Aussage klang so nach "Es gibt keine Alternative". :)

Was die Synchro angeht: Ein Event muss doch nicht zwangsweise synchronisiert (sprich: vom Hauptthread aufgerufen) werden. Der Indy-TCP-Server macht das ja mit dem Event OnExecute auch nicht.

In der SimpleTCP-Komponente synchronisiere ich aus Komfort-Gründen, aber erst, wenn ich die kompletten Daten, die gesendet werden, empfangen habe. Das können mal nur Kilobyte, mal aber auch Gigabyte sein, aber "geblockt" wird erst, wenn die Daten da sind.

Cu,
Udontknow
Grendel
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 443

Gentoo Linux, MacOS X, Win 2000
D5 Ent, D7 Ent, Lazarus, Anjuta, MonoDevelop
BeitragVerfasst: Mo 27.12.04 17:24 
Udontknow hat folgendes geschrieben:
Ahso, mißverstanden. Deine Aussage klang so nach "Es gibt keine Alternative". :)

Stimmt ja auch halb. Zumindest bei o.g. Komonente gibt es diese Alternative nicht. (So weit mir das bekannt ist)

Udontknow hat folgendes geschrieben:
Was die Synchro angeht: Ein Event muss doch nicht zwangsweise synchronisiert (sprich: vom Hauptthread aufgerufen) werden. Der Indy-TCP-Server macht das ja mit dem Event OnExecute auch nicht.

Anders. Wenn jedes Connection Objekt in einem eigenen Thread verwaltet wird, und dieser Thread auch direkt die Ereignisbehandlung bereitstellt wäre es sinnlos, wenn das Ereignis nicht auf dem Connection Object selber sondern vom Server (also im Hauptthread) ausgelöst wird.

Udontknow hat folgendes geschrieben:
In der SimpleTCP-Komponente synchronisiere ich aus Komfort-Gründen, aber erst, wenn ich die kompletten Daten, die gesendet werden, empfangen habe. Das können mal nur Kilobyte, mal aber auch Gigabyte sein, aber "geblockt" wird erst, wenn die Daten da sind.

Genau sowas meine ich ja.
Wenn das "OnReceive()" in diesem Fall im Server wäre und dabei das jeweilige Connection Object übergeben würde ginge das so eben nicht. bzw. würde man ständig Thread blocken.

Bis neulich ...


Zuletzt bearbeitet von Grendel am Mo 27.12.04 17:25, insgesamt 1-mal bearbeitet
Sqall Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 30



BeitragVerfasst: Mo 27.12.04 17:24 
Ah so. Hab zwar nicht wirklich alles verstanden aber ich guck jetzt mal nach dem event OnReceive. Dannach hab ich eigentlich auch gesucht. Wusste aber nciht wo ich das anwenden kann.

Habe gerade mal geguckt. bei meinem TcpServer ist aber kein event mit onrecieve enthalten. Ansonsten hätte ich es ja benutzt.Mhh, was jetzt. ich probier mal rum. Vielleicht krieg ich es ja hin bevor ihr antwortet :D
Udontknow
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2596

Win7
D2006 WIN32, .NET (C#)
BeitragVerfasst: Mo 27.12.04 18:24 
Grendel hat folgendes geschrieben:
Anders. Wenn jedes Connection Objekt in einem eigenen Thread verwaltet wird, und dieser Thread auch direkt die Ereignisbehandlung bereitstellt wäre es sinnlos, wenn das Ereignis nicht auf dem Connection Object selber sondern vom Server (also im Hauptthread) ausgelöst wird.

Ich glaube, du vermischt hier den ausführenden Thread und die Objekt-Instanz der Methode, die vom Thread ausgeführt wird. Ein Thread kann alles mögliche ausführen, natürlich auch Methoden des Objekts, das ihn erstellt hat. Genau das tut der Indy-Server. Er erstellt Threads für jede Connection, diese lösen dann ein Event auf der Server-Komponente aus, ohne das synchronisiert wird.
Ausserdem ist die Belegung von Ereignissen auf das Connection-Objekt zur Entwurfszeit ein wenig schwierig, da es ja zur Entwurfszeit noch keine Connections gibt. :wink:

Zitat:

Genau sowas meine ich ja.
Wenn das "OnReceive()" in diesem Fall im Server wäre und dabei das jeweilige Connection Object übergeben würde ginge das so eben nicht. bzw. würde man ständig Thread blocken.

Wieso? Die Synchronisierung ist doch kein Muss. Viele TCP-Server können auf eine Synchronisierung vollständig verzichten.

Cu,
Udontknow
Grendel
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 443

Gentoo Linux, MacOS X, Win 2000
D5 Ent, D7 Ent, Lazarus, Anjuta, MonoDevelop
BeitragVerfasst: Mo 27.12.04 22:29 
Udontknow hat folgendes geschrieben:
... Ein Thread kann alles mögliche ausführen, natürlich auch Methoden des Objekts, das ihn erstellt hat.

Richtig. Nur sollten mehrere Threads die Methode ihres Eltern-Objektes immer synchronisiert aufrufen, da sie sich sont gegenseitig überfahren.
Kann man ja ganz einfach nachstellen. Erzeuge mehrere Threads aus einem Objekt heraus und lass sie in unregelmäßigen Abständen eine Methode des Elter aufrufen. In dieser Methode schreibst Du z.B. einen String weg (FileStream).
Ohne synchronize wird das lustig. :)

Udontknow hat folgendes geschrieben:
Genau das tut der Indy-Server. Er erstellt Threads für jede Connection, diese lösen dann ein Event auf der Server-Komponente aus, ohne das synchronisiert wird.

Das glaube ich fast nicht (kann gerade nicht nachgucken).
Ich denke eher, daß die Connections ihrerseits Events abfeuern (ja ich weiß, daß events auch nur CallBacks sind), die dann von der Serverkomponente in entsprechende Events "umgesetzt" werden.
Und die Events der Connections selber sind mit Sicherheit synchronisiert. Vielleicht ja auch nur optional.
Das Problem wäre ja sonst, daß Du in der Ereignisbehandlungsroutine des Server Objektes niemals ernsthaft arbeiten könntest, da nicht-threadsichere Objekte dir reihenweise um die Ohren fliegen würden. (z.B. GUI Operationen)

Udontknow hat folgendes geschrieben:
Ausserdem ist die Belegung von Ereignissen auf das Connection-Objekt zur Entwurfszeit ein wenig schwierig, da es ja zur Entwurfszeit noch keine Connections gibt. :wink:

Na und, dann belegt man die halt zur Laufzeit. Wo ist das Problem?!

Udontknow hat folgendes geschrieben:
Wieso? Die Synchronisierung ist doch kein Muss. Viele TCP-Server können auf eine Synchronisierung vollständig verzichten.

Natürlich ist Synchronisation kein Muss. z.B. wenn der Connection Thread die komplette Arbeit erledigt. In dem Moment, in dem von den Threads z.B. in ein zentrales Logfile (s.o.) geschrieben werden soll, ist Synchronisation unumgänglich.

Bis neulich ...

Edit:

Sqall hat folgendes geschrieben:
Habe gerade mal geguckt. bei meinem TcpServer ist aber kein event mit onrecieve enthalten. Ansonsten hätte ich es ja benutzt.Mhh, was jetzt. ich probier mal rum. Vielleicht krieg ich es ja hin bevor ihr antwortet :D

Hat der auch nicht.
Du bekommst wie gesagt im OnAccept() ein TCustomIpClient Objekt. Das ist die gerade neu aufgebaute Verbindung. Und diese Verbindung (also der TCustomIpClient) hat ein OnReceive().

Bis neulich ...

Moderiert von user profile iconUdontknow: Postings zusammengeführt.
Udontknow
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2596

Win7
D2006 WIN32, .NET (C#)
BeitragVerfasst: Di 28.12.04 08:11 
Zitat:
Nur sollten mehrere Threads die Methode ihres Eltern-Objektes immer synchronisiert aufrufen, da sie sich sont gegenseitig überfahren.

Was meinst du mit überfahren? Die StVO gilt doch nicht in Delphi... :mrgreen:

Grundsätzlich stellt es überhaupt gar kein Problem dar, ein und dieselbe Methode von mehreren Threads gleichzeitig aufzurufen, solange dort nicht global deklarierte Daten geändert werden.

Zitat:
Das glaube ich fast nicht (kann gerade nicht nachgucken).
Ich denke eher, daß die Connections ihrerseits Events abfeuern (ja ich weiß, daß events auch nur CallBacks sind), die dann von der Serverkomponente in entsprechende Events "umgesetzt" werden.

Events sind nichts anderes als Pointer auf Prozeduren, wenn ich also ein Event FOnClick habe und ein Objekt dieses Event innerhalb des Threadkontexts aufruft, so wird natürlich auch die Prozedur, die durch dieses Event referenziert wird, durch den Thread ausgeführt.
Zitat:

Das Problem wäre ja sonst, daß Du in der Ereignisbehandlungsroutine des Server Objektes niemals ernsthaft arbeiten könntest, da nicht-threadsichere Objekte dir reihenweise um die Ohren fliegen würden. (z.B. GUI Operationen)

Es gibt Server, die so etwas nicht benötigen, z.B. ein TCP-Server, der Daten von einer Datenbank holt und diese an den TCP-Client weiterreicht. Für jeden Client wird eine eigene DB-Verbindung aufgebaut, und niemand kommt sich in die Quere.
Daher wird beim Indy-TCP-Server auch standardmäßig nicht synchronisiert, es obliegt dem Entwickler, das zu gegebener Zeit zu tun.

Cu,
Udontknow
Grendel
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 443

Gentoo Linux, MacOS X, Win 2000
D5 Ent, D7 Ent, Lazarus, Anjuta, MonoDevelop
BeitragVerfasst: Di 28.12.04 08:48 
Moin, moin!

Udontknow hat folgendes geschrieben:
Grundsätzlich stellt es überhaupt gar kein Problem dar, ein und dieselbe Methode von mehreren Threads gleichzeitig aufzurufen, solange dort nicht global deklarierte Daten geändert werden.

Oder eben nicht threadsichere Komponenten (z.B. GUI Krempel) verändert werden.

Udontknow hat folgendes geschrieben:
Events sind nichts anderes als Pointer auf Prozeduren, wenn ich also ein Event FOnClick habe und ein Objekt dieses Event innerhalb des Threadkontexts aufruft, so wird natürlich auch die Prozedur, die durch dieses Event referenziert wird, durch den Thread ausgeführt.

Ja schon klar. Hab doch extra dzu geschrieben, daß ich weiß, daß Events nur CallBack Prozeduren sind.
Und der Aufruf selber ist kein Problem sondern das was in der Aufgerufenen Prozedur gemacht wird.

Udontknow hat folgendes geschrieben:
Es gibt Server, die so etwas nicht benötigen, z.B. ein TCP-Server, der Daten von einer Datenbank holt und diese an den TCP-Client weiterreicht. Für jeden Client wird eine eigene DB-Verbindung aufgebaut, und niemand kommt sich in die Quere.
Daher wird beim Indy-TCP-Server auch standardmäßig nicht synchronisiert, es obliegt dem Entwickler, das zu gegebener Zeit zu tun.

Richtig. Hab ich ja ebenfalls geschrieben. In dem Moment, in dem der Thread die ganze Arbeit abnimmt brauch man natürlich nix synchronisieren. So wie in deinem Beispiel eben.
Würde man das ganze so erweitern, daß die Threads noch in ein zentrales Logfile schreiben müsste der Schreibzugriff synchronisiert werden.

Bis neulich ...
Udontknow
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2596

Win7
D2006 WIN32, .NET (C#)
BeitragVerfasst: Di 28.12.04 08:59 
Zitat:

In dem Moment, in dem der Thread die ganze Arbeit abnimmt brauch man natürlich nix synchronisieren. So wie in deinem Beispiel eben.
Würde man das ganze so erweitern, daß die Threads noch in ein zentrales Logfile schreiben müsste der Schreibzugriff synchronisiert werden.

Richtig, aber deshalb gleich das ganze Event zu synchronisieren wäre overkill, und deshalb wird es von Indy auch so nicht gemacht. Die Threads lösen die Events des Servers aus, und synchronisieren musst du selber.
Ich glaube, das Thema ist jetzt durch... :)

Cu,
Udontknow
Grendel
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 443

Gentoo Linux, MacOS X, Win 2000
D5 Ent, D7 Ent, Lazarus, Anjuta, MonoDevelop
BeitragVerfasst: Di 28.12.04 20:19 
Udontknow hat folgendes geschrieben:

Richtig, aber deshalb gleich das ganze Event zu synchronisieren wäre overkill, und deshalb wird es von Indy auch so nicht gemacht. Die Threads lösen die Events des Servers aus, und synchronisieren musst du selber.

Und wie bitte soll ich EIN Event, das von MEHREREN Threads ausgelöst wird nachträglich synchronisieren.
Ob die Threads nun direkt eine Prozedur aufrufen in der etwas nicht-threadsicheres abläuft oder ob sie erst ein Event (des Servers) aufrufen in dessen Handler das passiert ist doch ein und das selbe.
Synchronisieren können nunmal nur die Threads selber und nicht die Prozedur die unsynchronisiert aufgerufen wird.

Udontknow hat folgendes geschrieben:
Ich glaube, das Thema ist jetzt durch... :)

Das glaube ich nicht Tim :D

Bis neulich ...
Udontknow
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2596

Win7
D2006 WIN32, .NET (C#)
BeitragVerfasst: Mi 29.12.04 09:49 
Ai caramba!
Grendel hat folgendes geschrieben:

Und wie bitte soll ich EIN Event, das von MEHREREN Threads ausgelöst wird nachträglich synchronisieren.

Ob die Threads nun direkt eine Prozedur aufrufen in der etwas nicht-threadsicheres abläuft oder ob sie erst ein Event (des Servers) aufrufen in dessen Handler das passiert ist doch ein und das selbe.

Also, noch einmal von vorne. :)

Die Threads rufen jeder für sich die mit dem Event verbunde Prozedur auf. Um nun Probleme zu vermeiden, darf man keine globalen Daten einfach so ändern, man muß innerhalb des Events synchronisieren.



Hier, schau dir mal die Empfangsroutine vom meinem TSimpleTCPServer an. Die wird als Event der aggregierten TIdTCPServer-Komponente von den jeweiligen Threads aufgerufen.

ausblenden volle Höhe Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
89:
90:
91:
92:
93:
94:
procedure TSimpleTCPServer.ServerExecute(AThread: TIdPeerThread);
var Command:Integer;
var Stream:TStream;
var TempFile:String;
var BytesToTransfer,BytesTransferred,BytesToRead:Int64;
begin
  if (not AThread.Terminated) and (AThread.Connection.Connected) then
  try
    //set nonstopping breakpoint to ignore following exceptions
    AThread.Connection.ReadBuffer(Command, SizeOf(Command));
    //set nonstopping breakpoint to handle following exceptions

    //bytes to read?
    AThread.Connection.ReadBuffer(BytesToRead, SizeOf(BytesToRead));

    //if datasize is large, create a file stream,
    // else create faster memory stream
    if BytesToRead>=FSizeForFileStream then
    begin
      TempFile:=GetTempFile;
      Stream:=TFileStream.Create(TempFile,fmCreate)
    end
    else
      Stream:=TMemoryStream.Create;

    try
      Stream.Size:=BytesToRead;
      Stream.Position:=0;

      //triggering initial OnProgress event
      BytesTransferred:=0;
      BytesToTransfer:=BytesToRead;
      FCS.Enter;
      try
        FConnection:=FConnections.ByThread(AThread);
        FBytesTransferred:=BytesTransferred;
        FBytesToTransfer:=BytesToTransfer;

        if Assigned(FOnProgress) then
        AThread.Synchronize(HandleProgress);
      finally
        FCS.Leave;
      end;

      //receive data
      While BytesToRead>=FBytesForProgress do
      begin
        AThread.Connection.ReadStream(Stream,FBytesForProgress);
        BytesToRead:=BytesToRead-FBytesForProgress;
        BytesTransferred:=BytesTransferred+FBytesForProgress;

        //triggering OnProgress event
        FCS.Enter;
        try
          FConnection:=FConnections.ByThread(AThread);
          FBytesTransferred:=BytesTransferred;
          FBytesToTransfer:=BytesToTransfer;

          if Assigned(FOnProgress) then
            AThread.Synchronize(HandleProgress);
        finally
          FCS.Leave;
        end;
      end;

      if BytesToRead>0 then
        AThread.Connection.ReadStream(Stream,BytesToRead);
      Stream.Position:=0;

      //Closing writestream, reopening as readstream
      if Stream is TFileStream then
      begin
        Stream.Free;
        Stream:=TFileStream.Create(TempFile,fmOpenRead);
      end;

      //commandprocessing
      FCS.Enter;
      try
        FCommand:=Command;
        FConnection:=FConnections.ByThread(AThread);
        FStream:=Stream;
        AThread.Synchronize(HandleProcessCommand);
      finally
        FCS.Leave;
      end;
    finally
      //FStream.Free;
    end;
  except
    AThread.Connection.Disconnect;
    AThread.Terminate;
  end;
end;


Der Punkt ist, daß es eben zum größten Teil doch völlig threadsichere Vorgänge sind, wo jeder Thread nur lokale Daten der Prozedur nutzt, einzig und allein die Fortschrittsevents (HandleProgress) und das Verarbeiten der dann empfangenen Datenmenge (HandleProcessCommand) muss per Criticalsection und Synchronize geschützt werden.

Zitat:
Synchronisieren können nunmal nur die Threads selber und nicht die Prozedur die unsynchronisiert aufgerufen wird.

Wie jetzt? Ich synchronisiere, indem ich im Threadkontext in der Prozedur explizit Synchronize aufrufe. Es werden also nur Teile des Codes (nämlich die mit Synchronize übergebene Methode) synchronisiert, alles andere muss nicht der Reihe nach ablaufen.

Falls immer noch Mißverständnisse vorliegen, poste mal Beispielcode, damit man da nicht ständig aneinander vorbei redet (Das Gefühl habe ich ganz stark). :wink:

Cu,
Udontknow
Grendel
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 443

Gentoo Linux, MacOS X, Win 2000
D5 Ent, D7 Ent, Lazarus, Anjuta, MonoDevelop
BeitragVerfasst: Mi 29.12.04 10:53 
Udontknow hat folgendes geschrieben:
Wie jetzt? Ich synchronisiere, indem ich im Threadkontext in der Prozedur explizit Synchronize aufrufe. Es werden also nur Teile des Codes (nämlich die mit Synchronize übergebene Methode) synchronisiert, alles andere muss nicht der Reihe nach ablaufen.

Ok. Wir meinen offenbar doch das selbe und haben nur gründlich aneinander vorbei geredet :D
Natürlich läuft nicht der komplette Thread synchronisiert aber das auslösen des Events sollte synchronisiert sein.

Nun sind wir uns ja schließlich doch noch einig geworden.

Bis neulich ...
Udontknow
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 2596

Win7
D2006 WIN32, .NET (C#)
BeitragVerfasst: Mi 29.12.04 11:00 
Zitat:
aber das auslösen des Events sollte synchronisiert sein.


Nur um das noch mal klarzustellen: Die oben gepostete Prozedur wird ja als Eventhandler für TIDTCPServer.OnExecute genutzt, ist aber nicht an sich synchronisiert, dafür hat der Benutzer innerhalb der Event-Methode selber zu sorgen. Je nach Zielsetzung ist das nötig oder nicht nötig.

Cu,
Udontknow
Grendel
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 443

Gentoo Linux, MacOS X, Win 2000
D5 Ent, D7 Ent, Lazarus, Anjuta, MonoDevelop
BeitragVerfasst: Mi 29.12.04 11:04 
Udontknow hat folgendes geschrieben:
Nur um das noch mal klarzustellen: Die oben gepostete Prozedur wird ja als Eventhandler für TIDTCPServer.OnExecute genutzt, ist aber nicht an sich synchronisiert, dafür hat der Benutzer innerhalb der Event-Methode selber zu sorgen. Je nach Zielsetzung ist das nötig oder nicht nötig.

Ja. Hast Recht also so:
Zitat:
aber das auslösen des Events sollte je nach Anwendungsfall synchronisiert sein.


Bis neulich ...
Sqall Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 30



BeitragVerfasst: So 02.01.05 18:11 
So sieht das also aus *kaum was versteh*

Also wie es aussieht sollte ich mir nochmal gründlich threads angucken. Naja, das meiste hab ich ja verstanden. Und ich sollte mir das synchronisieren mal angucken.

mfg

Sqall