[himitsu]

Vornweg: Hierfür sind die Generics notwendig.

Also, nix Weltbewegendes .. hiermit kann man halt einfach nur verschiedene Prozeduren in eigenen Threads laufen lassen.
Diese Prozeduren können, unter Anderem Dank der Generics, auch mit eigenen Parameterdefinitionen versehen sein.
Bis zu 3 Parameter sind möglich.

zusammenfalten · markieren

Delphi-Quellcode:

Program ThreadHelperP;

Uses Windows, ThreadHelper;

Procedure Proc(Helper: TThreadHelperClass; Const i: Integer);
  Begin
    Beep(1000, 500);
    Sleep(i);
    Beep(1000, 500);
  End;

Procedure Proc2(Helper: TThreadHelperClass);
  Begin
    While Helper.Running do Begin
      Beep(5000, 200);
      Sleep(1000);
    End;
  End;

Begin
  RunAsThread<Integer>(Proc, 3000);

  TThreadHelper.RunAsThread(Proc2);
  Sleep(10000);
  TThreadHelper.StopAllGlobalThreads;

  // warten bis alle Threads beendet wurden
  While TThreadHelper.ActiveGlobalThreads > 0 do Sleep(10);
End.

Leider gibt es keine Generics für Prozeduren , drum mußte ich alles in 'ner Klasse (TThreadHelper) kapseln.
Geplant waren eigentlich nur die RunAsThread-Prozeduren, aber am Ende hatte es so wohl doch einige Vorteile.

Innerhalb der Threads kann man, ebenso wie bei den Thread-Prozeduren,
auch entsprechende Synchronize-Prozeduren aufrufen.



Es ist also nicht nötig sich erst eine eigene TThread-Klasse abzuleiten
oder sich mit der WinAPI auseinander zu setzen,
sondern kann seine Prozedur einfach und direkt starten
und das sogar mit Parametern, was doch sonst immer ein bissl schwieriger ist.

[edit]
In der 7zip liegt nun das Testprogramm, die Generics-Version und eine neue abgespreckte Version ohne Generics.

Hi,

ohne dein Projekt abwerten zu wollen (hab's mir noch nicht angeschaut, und kann es mangels D2010 auch gar nicht), wollte ich darauf hinweisen, dass jbg hier mal ein ähnliches Projekt vorgestellt hat. Vielleicht kannst du dir ja das ein oder andere von ihm abschauen.

durchaus auch einen Blick wert: OmniThreadLibrary

Aktuell arbeitet Primož an der OTL 2.0, ein paar Informationen dazu hat er in seinem Blog schon veröffentlicht: http://www.thedelphigeek.com/

Da find ich die Implementierung eines Futures von gabr besser (auch wenns nich 100%ig das gleiche ist). Außerdem ist es ein wenig unglücklich, dass die Procedure, die du ausführst schon so konstruiert sein muss, dass sie in nem ThreadHelper laufen kann.

jpg's kenn ich, aber wer sagt denn, daß man nicht auch mal rumspielen darf?



Wobei jbg's Code ja auf "brutale" Weise den Threadkontext tauscht und die Codeausführung vom aktuellen Thread in einen anderen verschiebt.

Hier ist es einfach nur so, daß man einen TThread startet und seine Prozedur von da aus aufrufen läßt ... also ohne irgendwelche "Tricks" und somit wirt es auch keine Probleme geben, wenn sich mal irgendwo etwas ändert. (dir wird bestimmt nicht entfallen sein, daß jbg an seiner Lib schon eine ganze Weile arbeitet und es auch einige Problemchen gibt/gab.)

Also im Prinzip nehme ich hier den "offiziellen" Standardweg über TThread, nur daß man statt selber ein TThread-Objekt zu erstellen und selber seine Funktion aufzurufen, dieses über einen vordefinierten TThread-Nachkommen aufrufen lassen kann.

(Was aber nicht heißt, daß ich jbg's Code nicht cool finde )


OK, hab die Unit etwas abgespeckt und die Generics ausgebaut.
Es wird nun zwar erstmal nur maximal ein Parameter unterstützt, aber das liese sich erweitern (hab halt einfach nur alles entfernt/umgebaut, was Generics benötigt).

Kennen wir uns? Ein Bekannter verneint auch immer alles doppelt:

markieren

Delphi-Quellcode:

(noWait: Boolean = False)
If not noWait Then

Aber wie du bereits sagtest, find ich es gut Alternativprodukte zu haben. (Auch wenns für D2k9++ ist )

Gut, 'ne kleine Version ohne Generics gibt's ja nun.
Ich weiß grade nicht seit wann die TObjectList das OwnsObject kennt, aber ab da sollte der Code nun laufen.
Ansonsten müßte man noch was gegen das Speicherleck machen, welches ohne dieses entstehen würde.

Zitat:

// TAsyncCalls.Invoke<TObject>(DoSomething, nil); wegen internal compiler error nicht mehr funktionsfähig

Das kommt mir bekannt vor ... solche Compilerfehler bei Generics kommen immer wieder mal vor

Danke.
OwnsObjects gibt es anscheinend schon länger, nur 2007 kommt mit dem Class Destructor nicht klar und kennt folgendes nicht:

markieren

Code:

[DCC Fehler] ThreadHelperNonGen.pas(22): E1030 Ungültige Compileranweisung: 'POINTERMATH'
[DCC Fehler] ThreadHelperNonGen.pas(23): E1030 Ungültige Compileranweisung: 'STRINGCHECKS'

E: TThread.Start gibts auch noch nicht.
Wurde damit jetzt der Bug behoben? Ok, die OH sagt mittlerweie ich soll nicht mehr Suspend/Resum benutzen.

OK, beim Class Destructor wußte ich nicht, seit wann es den gibt.
(hatte jetzt auch nicht dran gedacht diesen zu ersetzen ... war aber auch mein erstes Mal, wo ich diesen ausprobiert hatte)

STRINGCHECKS gibt es erst seit Delphi 2009 und der Rest wurde auch rausgenommen/geändert.

Zitat von himitsu:

aber wer sagt denn, daß man nicht auch mal rumspielen darf?

Darf man
Es ist einfach 'ne Spielerei um etwas die Grenzen und Möglichkeiten von Generics auszuloten.
Aber der praktische Nutzen ist im Prinzip nicht vorhanden.
Warum sollte man diese unglückliche Prozedure mit maximal einem Parameter aufrufen, wenn man doch lediglich die TThread-Klasse ableiten braucht?