Hallo,

ich arbeite an einem kleinen Mail-Programm welches auf den Indy-Komponenten basiert. Den "Indy-Layer" habe ich in Komponenten verpackt, welche die Verbindung aufbaut und halten soll, Downloads und Löschen von Mails etc. behandeln soll.
Da mein Programm dies im Hintergrund erledigen können soll - momentan freezed es ziemlich häufig, bi unterschiedlichen Aktionen - habe ich versucht diese Klasse(n) in Threads zu packen, welche einmal gestartet solange idlen sollen, bis ein Kommando, wie Download, Lösche oder Disconnect vom Hauptthread des Programms kommt. Dazu leite ich meine Basisklasse von TThread ab (ein Auszug aus meinem Programm):

zusammenfalten · markieren

Delphi-Quellcode:

  TConnection = class(TThread) //ist quasi ne abstrakte klasse
  protected
    IdSSLIO: TIdSSLIOHandlerSocketOpenSSL;
    procedure Execute; override;
  published
    IdMessage: TIdMessage;
    constructor Create(); virtual;
    destructor Destroy; override;
    function Connect: Boolean; virtual; abstract;
    procedure Disconnect; virtual;
    function IsConnected: Boolean;
    function IsReaded(idx: Integer): Boolean;
    function IsWorking: Boolean;
    procedure LoadMsg(index: Integer; full: boolean); virtual; abstract;
    procedure Refresh(LV: PListView); virtual; abstract;
    procedure Save; virtual; abstract;
    procedure SetAllItemsToReaded(ListView: TListView = nil);
    procedure SetAllItemsToUnreaded(ListView: TListView = nil);
    procedure SetReaded(idx: Integer; ListView: TListView);
    procedure SetUnreaded(idx: Integer; ListView: TListView);
  end;

  TConPOP3 = class(TConnection) //Lokale MailBox Verwaltung
  private
    IdPOP3: TIdPOP3;
    procedure CreatePOP3;
  public
    constructor Create(); override;
    destructor Destroy; override;
    function Connect: Boolean; override;
    procedure DelMail(index: Integer);
    procedure Disconnect; override;
    function GetUIs: TStrings;
    procedure LoadMsg(index: Integer; full: boolean); override;
    procedure Refresh(Sender: TObject);
    procedure RecreatePOP3;
    procedure ReRetrieve(index: Integer);
    procedure ResetPOP3;
    function RetrieveRAW(index: Integer): TStrings;
    procedure Save; override;
  end;

Das ganze war bisher eine ganz normale Klasse. Daher hier die Änderungen die ich vorgenommen habe, damit die Klasse in einem Thread läuft:

zusammenfalten · markieren

Delphi-Quellcode:

constructor TConnection.Create();
begin
  inherited Create(True);

//hier steht noch irrelevanter alter Code

  FreeOnTerminate := True;
  Priority := tpIdle;
  Resume;
end;

procedure TConnection.Execute;
begin
  WaitFor;

  //Never reachs this line!!!
end;

Soweit ich im Debugger sehe, werden die Threads erzeugt und existieren bis zum Programmende bzw. da wo ich sie mit ConPOP3.Free; beende. Fehlermeldungen, Speicherzugriffsverletzung oder Exceptions bekomme ich auch keine (mehr).


Mein eigentliches Problem ist, dass ich mir halt denke bei nem Aufruf:

markieren

Delphi-Quellcode:

{1}  StatusPanel.Visible := true; //<1 sek.
{2}  ConPOP3.LoadMsg(SelectedIndex, true); //20-30 sek.
{3}  StatusPanel.Visible := false; //<1 sek.

sollte, erst 1, dann 2 "und" 3 so ausgeführt werden, dass die Befehle in der Reihenfolge: 1,3,2 fertig werden. Jedoch wird 2 ausgeführt als wenn es in keinem Thread drin stecken würde, so dass ich auf die Reihenfolge 1,2,3 komme :-/


Langsam bin ich ratlos, weil ich bisher bzgl. der Freezes immer nur die Tipps finde "Packs doch einfach in einen Thread" ohne weitere Ausführung. Und bei den Thread-Problemen geht es immer nur um Synchronisationsprobleme, sowie bei den Thread-Tutorials pro Thread immer nur eine fest verdrahtete Funktion zu haben :-/

Du bist witzig: In der Execute-Methode tust du nichts und nur weil deine anderen Methoden plötzlich zu einer von TThread abgeleiteten Klasse gehören, sollen sie nicht mehr blockieren? Gethreaded wird nur das, was in der Execute-Methode steht. Du musst also in der Execute-Methode auf irgendein Signal warten und dann die entsprechende Aktion durchführen. In den anderen Methoden setzt du dann nur das Signal.

Und Zugriff auf GUI-Controls (hier TListView) aus dem Thread ist nicht. Das Programm wird dier permanent und unterschiedlichsten Stellen um die Ohren fliegen.

@Apollonius: Ich muss sagen, doch so hatte ich das verstanden, dass das dann nicht mehr blockieren würde, weil TThread das kapselt

@Bernhard Geyer: Das mit den Zugriffsproblemen ist mir soweit klar, hatte aber verstanden, dass man das mit nen paar "Synchronize" aufrufen hinbekommt?! Darum wollte ich mich jedenfalls erst als zweites kümmern.
Müssen in die Syncronized-Funktionen alle Sachen die auch von wo anders zugegriffen werden können oder nur die sachen die konsistent sein müssen? (Es ist mir z.B. an einigen Stellen egal ob der eine oder nen anderer Thread nen Button (de)aktiviert.)


Ok, mein Versuch oben funktioniert also nicht. An der Create etwas zu ändern macht keinen Sinn, da die Klasse sich einmal erstellt verbinden soll und die Verbindung halten können soll. Die Execute darf ich nicht überladen, soweit ich gefunden haben.

Also habe ich jetzt, soweit ich die Materie überblicken kann, wohl nur die Wahl:
a) jede Methode der oben genannten Klassen in eigene ("lokale") Threads zu verfrachten.
oder
b) für jede Methode 'ne zusätzliche Aufrufmethode schreiben, die dann mittels Attributen der Klasse, die Methode selektieren würde die ich eigentlich will und deren Paramter nachbildet, damit ne idle-Dauerschleife in Execute das aufgreifen kann.

Wie macht man das am Sinnvollsten? Nach a) oder b) oder macht man das ganz anders?
Wie lasse ich nen Thread idlen? Sleep hat in meinem obigen Code alles was in der Thread-Klasse lief vollkommen ausgebremst ud zudem volle CPU-Auslastung ergeben.

Klassischerweise erledigt man so etwas mit Events oder Semaphoren: In der Execute-Methode wartest du auf die Semaphore und wenn das Warten erfolgreich war, liest du aus einer (Thread-)Liste einen Befehl aus. In allen anderen Methoden fügst du den Befehl an die Liste an und signalisierst die Semaphore.
Zum Beenden signalisierst du ebenfalls die Semaphore, in der Execute-Methode musst du dann Terminated prüfen.

Hm, ich dachte eigentlich dass die TThread-Komponente mir das abnehmen sollte, finde aber immer noch nicht wie. Kannst du mir vielleicht nen paar Codebeispiel geben?!

Insbesondere zu (Thread-)Listen, Semaphoren und wie ich dann in der Execute-Methode richtig idle.

Mein Problem ist hauptsächlich die konkrete praktische Umsetzung in Delphi. Die grundsätzlichen Konzepte sind soweit klar, auch wenn ich nicht gedacht hätte, dass ich in gerade in Delphi alles von der API aufwärts selber machen muss und bereits so ein umfassendes Thread-Management implementieren muss :-/

In der von TThread abgeleiteten KLasse brauchst du als Member-Variablen eine TThreadList und ein THandle (die Semaphore).
Im Konstruktor erstellst du sie (mit Create bzw. CreateSemaphore - die Semaphore braucht keinen Namen und keine SecurityAttributes, aber einen Anfangszähler von Null). Außerdem deklarierst du eine Basisklasse für Befehle, am Besten mit einer abstrakten Execute-Methode.
Für jeden einzelnen Befehl leitest du von dieser Basisklasse ab, ergänzt nötige Felder und überschreibst die Execute-Methode. In den Methoden der von TThread abgeleiteten Klasse erstellst du dann einfach die entsprechende Klasse, füllst die Felder und hängst die Instanz an die Threadliste an, außerdem signalisierst du die Semaphore.
In der Execute-Methode der von TThread abgeleiteten Klasse wartest du in einer Schleife mit WaitForSingleObject auf die Semaphore. Anschließend prüfst du, ob Terminated True ist und brichst gegebenenfalls ab. Andernfalls holst du die Befehlsinstanz ab, rufst deren Execute-Methode ab und gibst sie frei. Danach wartest du wieder auf die Semaphore.

Im Forum findest du so etwas auch schon fertig. Suche mal nach Worker-Thread.