Zitat von Sir Rufo:

@Frank
Den Thread im Suspended-Mode zu starten macht irgendwie keinen Sinn, da der doch schon durch den Event wartet.

Sicher? Wird der Thread nicht bei Inherited Create(false) schon gestartet? Dann ist der Event noch nicht Created!

Zitat von Sir Rufo:

Ich würde auch nicht TThread.Terminate überschreiben, sondern Thread.TerminatedSet , denn das ist schon als virtual deklariert und somit zum Überschreiben gedacht.

Wenn Du eine Delphi Version hast die diese Implementierung schon hat, gebe ich dir Recht. D2007 hat das noch nicht.

Zitat von Sir Rufo:

@
Die Klasse selber würde ich noch als abstract deklarieren (nur wegen der Dokumentation), denn ohne Ableitung ist die ja so nicht lauffähig.

OK.. Kann man machen... Obwohl der Compiler das auch so meldet.. Aber Du hast recht... Bin neu im "Abstract" Bereicht

Zitat von Sir Rufo:

@
Einfach so die Exception wegfangen ist auch nicht gerade schön

Das ist Teil unseres "Unser Programm hat keine Exceptions" Konzept... Bitte hierzu keine Diskussion anfangen, Danke...

Mavarik

Zitat von Dejan Vu:

Zitat von Mavarik:

Ich würde die Klasse nicht ThreadExecuter, sondern lieber "TSaugdenAkkuleer" oder "TCPUCycleKiller" nennen...

Nicht jeder Entwickelt für akkubetriebene Küchenschneidbretter.

Und auch nicht für Notebooks?

Zitat von Sir Rufo:

...und wenn fangen, dann nur so:

markieren

Delphi-Quellcode:

try
  MyExecute;
except
  // Nur spezielle Exceptions fangen, die MyExecute bewusst ausgelöst hat
  // Alle anderen unvorhergesehenen werden durchgereicht
  on E:MyExecuteException do
    begin
    end;
end;

Hmm... Kommentarlos? Noch nicht mal loggen? Gewagt, gewagt. Würde ich nie nicht niemals so machen. Wenn es eine Exception als Flusskontrolle gibt, dann muss das im 'MyExecute' abgefangen werden. Diese Methode hat sorge zu tragen, das sie sauber terminiert, bzw. kontrolliert Exceptions weiterleitet. Dann muss aber in der aufrufenden Methode eine vollständige Exceptionbehandlung erfolgen, meinst Du nicht?

Zitat von Mavarik:

Und auch nicht für Notebooks?

Nö. Nur für Industrieboliden. Aber mal im Ernst: Du hast Recht. Stromsparen tut nicht weh und ist auch nicht verkehrt.

Wahrscheinlich verbrauchen sauber behandelte Exceptions zuviel Strom

Zitat von Dejan Vu:

Hmm... Kommentarlos? Noch nicht mal loggen? Gewagt, gewagt.

Das hab ich nicht gesagt... Ich wollte Euch nicht mir meinem "Restsource" verwirren...

Zitat von Dejan Vu:

Wenn es eine Exception als Flusskontrolle gibt, dann muss das im 'MyExecute' abgefangen werden. Diese Methode hat sorge zu tragen, das sie sauber terminiert, bzw. kontrolliert Exceptions weiterleitet. Dann muss aber in der aufrufenden Methode eine vollständige Exceptionbehandlung erfolgen

Das ist eine der wenigen Stellen wo ich Java (Direktive throws für Methoden) vermisse. In C# bubbelt auch alles immer weiter nach oben (wie in Delphi), oder?


Aber irgendwie kommen wir vom ursprünglichen Thema ab...

Zitat von Mavarik:

Das hab ich nicht gesagt... Ich wollte Euch nicht mir meinem "Restsource" verwirren...

Ich meinte ja auch nicht dich mit dieser Anmerkung.

Zitat von Der schöne Günther:

Das ist eine der wenigen Stellen wo ich Java (Direktive throws für Methoden) vermisse. In C# bubbelt auch alles immer weiter nach oben (wie in Delphi), oder?

OT: Ja, wir kommen vom Thema ab, ja, bei C# bubbelt es auch weiter nach oben wie in Delphi und Java und nein, ich vermisse die 'throws' Direktive nicht, denn es ist kein Mehrwert an Übersichtlichkeit und Stabilität (vor allen Dingen nicht: Produktivität).

Meiner Meinung nach kann man über Exceptions mal wieder einen Fred aufmachen. Aber hier ist, dank Günther, dem Schönen, auch von meiner Seite aus Schluss.

Zitat von Mavarik:

Zitat von Sir Rufo:

@Frank
Den Thread im Suspended-Mode zu starten macht irgendwie keinen Sinn, da der doch schon durch den Event wartet.

Sicher? Wird der Thread nicht bei Inherited Create(false) schon gestartet? Dann ist der Event noch nicht Created!

Nein, definitiv nicht!

PS
Wenn du so eine Angst davor hast, dann leg die Erzeugung des Events einfach vor das inherited Create( False ); .

markieren

Delphi-Quellcode:

constructor TMyThread.Create;
begin
  E_Event := TEvent.Create(NIL,false,false,'');
  FRunning := false;

  inherited Create( False ); // nein, nicht schlafen :)

  FreeOnTerminate := false;
end;

Der Thread wird erst nach dem kompletten Abarbeiten des Destructors Constructors (Danke an Uwe) gestartet (das ist absolut gesichert!). Und das auch nicht direkt sofort, sondern auch erst nach einer gewissen Dauer, weil der Thread erstmal warten muss, bis er an der Reihe ist.

Führe einfach mal dieses hier aus und wundere Dich

zusammenfalten · markieren

Delphi-Quellcode:

type
  TMyThread = class( TThread )
  protected
    procedure Execute; override;
  end;

procedure TMyThread.Execute;
begin
  inherited;
end;

procedure ThreadTest;
var
  LThread : TThread;
  LCount : Int64;
begin
  LCount := 0;
  LThread := TMyThread.Create( False );
  try
    while not LThread.Started do
      Inc( LCount );
  finally
    LThread.Free;
  end;
  Writeln( 'Gestartet nach ', LCount, ' Loops' );
end;

Zitat von Sir Rufo:

Der Thread wird erst nach dem kompletten Abarbeiten des Destructors gestartet (das ist absolut gesichert!).

Constructors!

[QUOTE=Mavarik;1264399]

Zitat von stoxx:

Autsch...

Ich würde die Klasse nicht ThreadExecuter, sondern lieber "TSaugdenAkkuleer" oder "TCPUCycleKiller" nennen...

Dafür gibt es doch Waitfor oder Multisyncwait damit der Thread schläft so lange er nicht gebraucht wird.

Dein Ton ist ja gerade noch so freundlich, aber schon recht grenzwertig.
Woher nimmst Du die Behauptung, dass die Klasse intern das sleep nicht mit Waitfor realisiert?
Du kannst ihn doch programmieren, wie Du Lust hast, und den FunctionCall auch erst nach einem einkommenden Event generieren.

Wenn ich aber ständig eine Response brauche, weil ständig Dinge getan/geprüft werden müssen, , dann muss er wohl in der Tat auch ständig bereit sein, um gewisse Dinge zu erledigen.