Workerthread: Der Diener im Hintergrund

[alzaimar]

Hi Assertor,

Ich bau das mal ein und stelle es im 1.Post wieder rein.

Edit: Achso, äh.. Danke für das Kompliment.

[Assertor]

Hi Alzaimar,

Zitat von alzaimar:

Edit: Achso, äh.. Danke für das Kompliment.

Bitte, gerne

[Assertor]

Hi,

noch eine kleine Verbesserung, um das Debugging in neueren Delphi Versionen zu vereinfachen:

Delphi-Quellcode:

--- D:/Downloads/csWorkerThreadPool.pas   Sat Nov 29 15:30:22 2008
+++ D:/csWorkerThreadPool.pas   Sun May 17 01:38:13 2009
@@ -113,6 +113,7 @@
     fMsg: String;
     Procedure DoAction;
 {$ENDIF}
+    procedure SetName;
     Procedure Run;
     Procedure DoOnException;
     procedure DoNotify;
@@ -265,6 +266,35 @@
 
 { TWorkerThread }
 
+{$IFDEF MSWINDOWS}
+type
+  TThreadNameInfo = record
+    FType: LongWord;     // must be 0x1000
+    FName: PAnsiChar;    // pointer to name (in user address space)
+    FThreadID: LongWord; // thread ID (-1 indicates caller thread)
+    FFlags: LongWord;    // reserved for future use, must be zero
+  end;
+{$ENDIF}
+
+procedure TWorkerThread.SetName;
+{$IFDEF MSWINDOWS}
+var
+  ThreadNameInfo: TThreadNameInfo;
+{$ENDIF}
+begin
+{$IFDEF MSWINDOWS}
+  ThreadNameInfo.FType := $1000;
+  ThreadNameInfo.FName := 'csWorkerThread';
+  ThreadNameInfo.FThreadID := $FFFFFFFF;
+  ThreadNameInfo.FFlags := 0;
+  try
+    RaiseException($406D1388, 0, sizeof(ThreadNameInfo) div sizeof(LongWord),
+      @ThreadNameInfo);
+  except
+  end;
+{$ENDIF}
+end;
+
 Constructor TWorkerThread.Create(aID: Integer; aJobList: TWorkerThreadJobList);
 Begin
   Inherited Create(True);
@@ -302,6 +332,7 @@
 
 Procedure TWorkerThread.Execute;
 Begin
+  SetName;
   While Not Terminated Do Begin
     fCurrentJob := fJobList.WaitForNextJob;
     If Assigned(fCurrentJob) Then Begin

Das benennt die Threads dann ordentlich, so daß man diese im Debugger auch erkennt Ich weiß aus dem Kopf nicht, ob die Exception für benannte Threads < Delphi 2006 Probleme macht, vielleich packst Du noch ein IFDEF rein, damit es nur > Delphi 2006 verwendet wird.

Gruß Assertor

[alzaimar]

Davon von den @@ Tags habe ich noch nie etwas gehört. Kannst Du mir kurz erklären, worum es dabei geht?

[Win32.API]

Das ist nur eine Darstellungsform von Unterschieden zwischen zwei Versionen.

Zitat:

++ -> Datei 1
-- -> Datei 2
+ -> Hinzugefügt
- -> Gelöscht
@@ -> Vieleicht Zeilen angaben?

Also alles, wo ein + vorsteht, ist neu und muss ergänzt werden.

--win32

[alzaimar]

Aha. Ich habe das mal eingebaut und geprüft. Delphi 6 meckert bei der Ausführung mit einer 'external Exception', läuft ansonsten durch. Ich habe das dann aber nur für Delphi 2006 und höher aktiviert.

Zur Ermittlung der Delphi-Version habe ich 'JEDI-SDL.INC' verwendet. Wenn es eine andere/bessere Möglichkeit gibt, die Delphi-Version zu ermitteln, immer her damit.

Update wie immer im 1.Post.

[Assertor]

Hi,

@Win32.API: Danke, warst schneller mit dem Erklären

Zitat von alzaimar:

Aha. Ich habe das mal eingebaut und geprüft. Delphi 6 meckert bei der Ausführung mit einer 'external Exception', läuft ansonsten durch. Ich habe das dann aber nur für Delphi 2006 und höher aktiviert.

Zur Ermittlung der Delphi-Version habe ich 'JEDI-SDL.INC' verwendet. Wenn es eine andere/bessere Möglichkeit gibt, die Delphi-Version zu ermitteln, immer her damit.

Ich nutze immer gerne die Compilers.inc von Mike Lischke und Jim Kueneman. Das ist die Include für die VirtualTreeView. Link zum Source (steht unter der MIT Lizenz): http://new.lischke-online.de:8080/br.../Compilers.inc

Dann einfach im Source um alle Änderungen ein
{$IFDEF COMPILER_6_UP}...{$ENDIF} Das mit der Änderungsdatei war gestern einfacher, um die geänderten Stellen zu finden - war etwas faul Tools wie WinMerge (Bild) erstellen sowas und sind eine erhebliche Arbeitserleichterung.

Gruß Assertor

[alzaimar]

Gut, diese JEDI-SDL.Inc macht im Prinzip das Gleiche...

[Assertor]

Hi,

Zitat von alzaimar:

Gut, diese JEDI-SDL.Inc macht im Prinzip das Gleiche...

Ja, nur die Lizenz der Compilers.inc ist noch liberaler. Für Projekte von Entwicklern, die keine JEDIs einsetzen vielleicht besser.

Außerdem nimmt die JEDI-SDL.inc soweit ich sehen kann auch noch andere Änderungen an den Compiler Einstellungen vor (z.B. {$F+,Q-,R-,S-,I-,A+}). Das braucht der Diener im Hintegrund nicht und führt u.U. - wenn projektweit - zu Probleme oder ungewünschten Einstellungen.

Bei der Compilers.inc werden wirklich nur die Compiler festgestellt, kein Rumdrehen an Einstellungen.

Gruß Assertor

[sundance]

@alzaimar:
Erst mal vielen Dank für deine Mühe, die du in diese Unit gesteckt hast. Ich bin gerade dabei, in einem von meinen kleinen "Projekten" davon zu profitieren....

Ein paar Fragen/Anmerkungen hätte ich aber doch:

- Was bezweckst du mit der Methode TWorkerThreadPool.Notify?

- Wie würdest du es anstellen, auf die Abarbeitung aller Jobs in der List zu warten, um z.B. irgendwelche Controls zu aktualisieren oder eine Statusmeldung auszugeben? (Polling auf TWorkerThreadPool.PendingJobCount = 0 ist ja wohl nicht der beste Weg...)

- In diesem Thread war mal eine Anmerkung:

Zitat:

Eins hab ich aber nicht ganz verstanden:
Wenn man Synchronized auf true setzt, wird der ganze Job über Synchronize(Run) ausgeführt. Wird das nicht zu einer blockierenden Operation dann ? Dann kann ich doch eigentlich diese Arbeit gleich im Haupt-VCL-thread ausführen lassen.

Zitat:

stimmt auffallend...

Nun ist das aber immer noch so drin:

Delphi-Quellcode:

If fCurrentJob.Synchronized Then
  Synchronize(Run)
Else
  Run;

Läuft der synchronisierte Thread nun autark oder nicht?
(na ja, vielleicht habe ich deine Source auch noch nicht ganz verstanden...)

.sundance.