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?

Mir ist noch nicht ganz klar, warum du, wenn du schon Delphi 2010 nutzt, keine anonymen Methoden benutzt. Das würde das ganze viel schlanker machen.