ThreadPool 1.0.9 für Delphi 2010-XE

[Zwoetzen]

Laut Google sollen die Klassen-Konstruktoren erst ab Delphi2010 unterstützt werden


(Aus der Fehlermeldung

Zitat von DCC Fehler:

E2123 PROCEDURE, FUNCTION, PROPERTY oder VAR erwartet

würde ich auch schließen, dass D2009 allgemein kein constructor bzw. destructor nach einem class erwartet. Habe trotzdem mal die verschiedenen Sichtbarkeiten durchprobiert: Wie zu erwarten ohne Erfolg )

[WladiD]

Zitat von Zwoetzen:

Laut Google sollen die Klassen-Konstruktoren erst ab Delphi2010 unterstützt werden


(Aus der Fehlermeldung

Zitat von DCC Fehler:

E2123 PROCEDURE, FUNCTION, PROPERTY oder VAR erwartet

würde ich auch schließen, dass D2009 allgemein kein constructor bzw. destructor nach einem class erwartet. Habe trotzdem mal die verschiedenen Sichtbarkeiten durchprobiert: Wie zu erwarten ohne Erfolg )

Alles klar Zwoetzen,

danke für die Information (war zu faul zum googeln ), werde demnächst (bin grad an was anderem dran) die erwähnte Compiler-Weiche einbauen und mich hier wieder melden.

[WladiD]

Habe eine ungeteste Anpassung für Delphi 2009 eingebaut und ins Repository eingespielt:

ThreadPool (Revision 11)

Musste die bewährte "Compilers.inc" von Mike Lischke einbinden.

Kann das jemand testen und mir mitteilen, ob es sich damit jetzt compilieren lässt?

Dank im Voraus!

[Bernerbaer]

Danke für Deine Änderungen, aber:

ThreadPool lässt sich nun ohne Fehlermeldung kompilieren.

Die beiliegenden Demos stürzen jedoch ab, im folgenden die ersten Fehlermeldungen mit dem angezeigten Codeabschnitt:

Code:

function IsTaskValid(Task:TPoolTask):Boolean;
   begin
      Result:=Owner.Tasks.IndexOf(Task) >= 0;
   end;

->Erste Gelegenheit für Exception bei $76EDFBAE. Exception-Klasse EAccessViolation mit Meldung 'Zugriffsverletzung bei Adresse 00475AF1 in Modul 'PrimePoolProject.exe'. Lesen von Adresse 00000000'. Prozess PrimePoolProject.exe (4432)

Code:

procedure TPoolManager.WorkerTerminated(TerminatedWorker:TPoolWorker);
begin
   BeginWriteWorkers;
   try
      Workers.Remove(TerminatedWorker);
   finally
      EndWriteWorkers;
      MainSignal.SetEvent;
   end;
end;

-> Erste Gelegenheit für Exception bei $76EDFBAE. Exception-Klasse EAccessViolation mit Meldung 'Zugriffsverletzung bei Adresse 00475AF1 in Modul 'PrimePoolProject.exe'. Lesen von Adresse 00000000'. Prozess PrimePoolProject.exe (4432)

[WladiD]

Zitat von Bernerbaer:

Die beiliegenden Demos stürzen jedoch ab...

Kommt der Fehler sofort nach dem Programmstart oder erst wenn Sie auf den Button "Add tasks" klicken. Gibt es irgendeine Ausgabe im Memo, kommt die AV sporadisch oder immer an der selben Stelle. Oder treten die Fehler gar in meinen Kompilaten auf?

Fragen über Fragen. Hätte ich mir doch gleich denken können, dass man für keine "Plattform" programmiert, die man selbst nicht hat/testen kann.

[Bernerbaer]

Antworten

1. Der Fehler tritt erst auf wenn Add Task geklickt wird, der Fehler tritt erst am beim letzen (?) Durchlauf der Schleife for c:= 0 to Steps - 1 auf
2. Nein, im Memo werden keine Einträge angelegt
3. Die beiliegenden Kompilate der Demos laufen problemlos
4. Der Fehler tritt bei den vom mir kompilierten Demos immer auf.

[WladiD]

Zitat von Bernerbaer:

Antworten

1. Der Fehler tritt erst auf wenn Add Task geklickt wird, der Fehler tritt erst am beim letzen (?) Durchlauf der Schleife for c:= 0 to Steps - 1 auf
2. Nein, im Memo werden keine Einträge angelegt
3. Die beiliegenden Kompilate der Demos laufen problemlos
4. Der Fehler tritt bei den vom mir kompilierten Demos immer auf.

Generics/Closures waren neu in D2009 = alpha
Generics/Closures wurden in D2010 verbessert = beta
Generics/Closures wurden in DXE weiter verbessert = stable?

So oder so ähnlich wird es wohl sein. Genau da vermute ich den Fehler. Daher werde ich das bisher versuchte wieder droppen und nicht weiter probieren etliche Workarounds einzubauen, um mit D2009 kompatibel zu sein. Der ganze ThreadPool sollte ursprünglich komplett auf Generics basieren, welchen man nur die spezielle Task-Klasse übergibt, doch dort scheiterte ich, weil der Support der Generics noch nicht fehlerfrei ist, damit will ich sagen, dass ich schon mit 2010er meine Probleme hatte. So ist das mit neuen Möglichkeiten, doch irgendwann muss man sie nutzen um einen Nutzen zu erlangen.

Nichtsdestotrotz ist es Open Source, also wenn das jemand hinmoddeld, dass es funktioniert, dem ist ein Eintrag unter Credits/Copyrights sicher.

[WladiD]

Soeben habe ich die neue Version 1.0.1 veröffentlicht. (Links siehe 1. Beitrag)

Neben einigen Optimierungen enthält es jetzt die Unterstützung für priorisierbare Tasks. Ableitende Tasks können die Eigenschaften TPoolTask.Priority oder TPoolTask.PriorityRaw veröffentlichen und der entsprechende Manager muss die Eigenschaft TPoolManager.SortTasks auf TRUE setzen um die Sortierung zu aktivieren.

Wenn mehr Aufgaben hinzugefügt werden, als gleichzeitig abgearbeitet werden können, so kommen die Tasks mit der höheren Priorität eher dran.

Ach ja, als Voraussetzung bleibt: ab Delphi 2010

[mquadrat]

Was vielleicht noch für den einen odere anderen nützlich sein könnte, wären Abhängigkeiten der Aufträge, so dass B erst nach A ausgeführt wird.

Prinzipiell ist die Sache super. Für mich zwar mangeld D2010/XE nicht nutzbar, aber es zeigt, dass die Community zumindest noch nich ganz kapituliert hat

[WladiD]

Zitat von mquadrat:

Was vielleicht noch für den einen odere anderen nützlich sein könnte, wären Abhängigkeiten der Aufträge, so dass B erst nach A ausgeführt wird.

Das ist schon ohne weiteres Zutun möglich:

Delphi-Quellcode:

var
  Task:TMyTask;
begin
  Task:=TMyTask.Create(Owner);
  // Task mit Daten füllen
  Task.OnDone:=procedure(Sender:TObject)
  var
    DependTask:TMyTask;
  begin
    if TMyTask(Sender).State <> tsSuccess then
      Exit;
    DependTask:=TMyTask.Create(Owner);
    // DependTask mit Daten füllen

    TMyPoolManager.AddTask(DependTask);
  end;
  
  TMyPoolManager.AddTask(Task);
end;

Zitat von mquadrat:

... die Community zumindest noch nich ganz kapituliert hat"

Ich hoffe, dass diese Aussage sich nicht auf die These "Delphi ist tot" bezieht. Native (abwertend auch unmanaged) Code wird auch in 20 Jahren eine Rolle spielen. Beides muss sich nicht zwangsweise ausschließen. Hier ist eine ausführlichere Antwort: www.isdelphidead.com ?