Wie versendest du denn Strings mit PostMessage?

Sollte kein Problem sein, da ja alles im selben Prozess bleibt.

Wenn es ein Pointer auf einen lokalen String ist, wird's potenziell ekelig.

Nein. Ich mache mir für sowas immer Records. Das erste ist ein InUse:Boolean. Ist der Record belegt, nehm ich den nächsten oder warte bis einer frei wird.

Da wo ich "reinposte" sieht der anfang immer so aus

markieren

Delphi-Quellcode:

procedure TReadDataFrm.RefreshRDObj(var Msg: TMessage);
var
   i      :Integer;
begin
      i := Integer(Msg.lParam);

da habe ich dann die nummer auf dem record, der "zu mir" gehört. Der Record ist Global und da stehen dann alle sachen drinne die ich in dem moment brauche. Strings,Integer usw..

Ich habe nun mal SendMessage genommen. Da der fehler nicht reproduzierbar ist, kann ich nur warten....

Zitat von DelTurbo:

Da habe ich dann die nummer auf dem record, der "zu mir" gehört. Der Record ist Global und da stehen dann alle sachen drinne die ich in dem moment brauche. Strings,Integer usw..

Hmmm, warum nimmst du keine TCollection und definierst dir ein passendes TCollectionItem dazu.
Von dem neuen TCollectionItem übergibst du per PostMessage oder SendMessage die ID (nicht den Index!) und schickst das auf die Reise. Der Empfänger kann nun aus dieser Collection sich das passende Item (mit der ID) herausnehmen und hat auch alle Informationen.

Generell würde ich auch die Jobs nicht als Thread definieren, sondern die Jobs durch einen WorkThread ausführen lassen.
Der WorkThread wird über einen WorkManager gestartet und dieser verwaltet passenderweise auch noch die Collection mit den Nachrichten.

Hier mal ein schnell hingetippeltes Projekt

zusammenfalten · markieren

Delphi-Quellcode:

type
IWorkManager = interface
procedure SendMessage(<ParameterListe anpassen>);
procedure PostMessage(<ParameterListe anpassen>);
end;

// Interface für den WorkJob
IWorkJob = interface
procedure SetWorkManager( aWorkManager : IWorkManager );
procedure DoExecute;
end;

TWorkThread = class( TThread )
private
  fWorkJob : IWorkJob;
protected
  procedure Execute; override;
public
  constructor Create( CreateSuspended : Booelan; aWorkJob : IWorkJob );
end;

TWorkManager = class( TInterfacedObject, IWorkManager )
public
  procedure AddJob( aWorkJob : IWorkJob );
end;

procedure TWorkManager.AddJob( aWorkJob : IWorkJob );
begin
  aWorkJob.SetWorkManager( Self );
  with TWorkThread.Create( True, aWorkJob ) do
  begin
    FreeOnTerminate := True;
    Resume;
  end;
end;

Es gibt auch noch diese OmniThreadLibrary die sowas schon direkt alles mitbringt (glaube ich).
Sowas baue ich aber lieber selber

Also ich kapsle einen String in einer Klasse. Das ist bestimmt oversized, aber bisher hatte ich damit keine Probleme...
(Das hier ist allerdings aus dem Gedächtnis)

zusammenfalten · markieren

Delphi-Quellcode:

Type
  TStringContainer = Class
  Public
     MessageString : String;
     Constructor Create (aMessage : String);
  End;

Constructor TStringContainer.Create (aMessage : String);
Begin
  MessageString := aMessage
End;

...
Procedure TMyThread.SendAString (AString : String);
Begin
  PostMessage(MainHandle, WM_STRING, Integer(TSTringContainer.Create(aString)),0);
End;

...
Procedure TMainTask.ReceivStringMessageHandler (Var Msg : TMessage);
Begin
  DoSomethingWith(TStringContainer(Msg.wParam).MessageString);
  TStringContainer(Msg.wParam).Free
End;

Is das ok so?

Nachtrag: Da mir das mit der Referenzzählung bei Strings nicht geheuer ist, mache ich das so.


@Sir Rufo: Threads mit FreeOnTerminate habe ich mir abgewöhnt, denn wenn ich die Anwendung beende und der Thread noch im Speicher rumfleucht, bekomme ich jedesmal eine schöne Exception, denn der Code zum Terminieren eines Threads baut darauf auf, das die Classes.pas noch nicht ihren finalize-Teil durchlaufen hat.

Zitat von Sir Rufo:

markieren

Delphi-Quellcode:

  with TWorkThread.Create( True, aWorkJob ) do
  begin
    FreeOnTerminate := True;
    Resume;
  end;

Ein Spiel mit dem Feuer. Mit Glück geht sowas gut, aber will man sich darauf verlassen? Nicht umsonst ist Resume mittlerweile als deprecated gekennzeichnet. Zitat aus der Hilfe:

Zitat:

Warnung: Die Methoden Resume und Suspend sollten nur für das Debuggen verwendet werden.

Hintergrund unter anderem:
Wenn der Thread zu schnell fertig ist bevor Resume beendet ist, zieht das FreeOnTerminate dem Code den Boden unter den Füßen weg. Und wenn es nur passiert, weil im Thread eine Exception auftritt, ausschließen kann man so etwas jedenfalls kaum. Dazu gibt es auch umfangreiche Diskussionen, unter anderem auch im Embarcadero Forum unter Beteiligung von deren Entwicklern. Das Fazit ist überall das gleiche: Nie Resume verwenden ist das beste.

Deshalb rate ich stattdessen dringend zu einer sauberen Lösung. Insbesondere hier im Beispiel ist das ja denkbar einfach: Einfach den Thread nicht suspended starten...

Zitat von DelTurbo:

Apprun ist auch Global. Es wird alle 100ms auf 1 gesetzt, über einen normalen TTimer.

Ich frage mich die ganze Zeit wozu das ganze eigentlich global ist. Du kannst dir doch Speicher reservieren, per Message an deinen Hauptthread schicken und der gibt den wieder frei. Dann kannst du dir die ganze zusätzliche Synchronisation sparen.

Und das mit dem Timer kannst du dir dann auch sparen. Denn der Thread kann sich einfach kurz mit Sleep schlafen legen und weitermachen.

Ansonsten gibt es auch noch Events (CreateEvent, SetEvent, ...) um die Signale hin- und herzuschicken. Die sind auch threadsicher.

Zitat von DelTurbo:

Mit der Variante aus dem ersten post, habe ich ein prg gemacht was bis zu 200 threads zeitgleich laufen hat.

Wobei so viele Threads das ganze natürlich sehr stark ausbremsen, wenn die wirklich zeitgleich arbeiten und nicht größtenteils schlafen.

Hi,
also ich weiss nun nicht ob das mit AppRun so eine grosse rolle spielt. Ich habe es einfach in der "unit1" deklariert und fertig. Was soll ich für (theoretisch einem Byte) speicher "hohlen". Find ich bissl umständlich.

Zum Thread. Der soll nicht schlafen, der soll arbeiten. Den gedanken gang kann ich leider nicht nachvollziehen. Ich habe das nun endlich so schnell, das ich mit bis zu 150MBit (im GBitLan) den MySqlServer "anblasen" kann. Und dann soll ich ein sleep einbauen? Sorry, das verstehe ich auch nicht.

Zu den 200 Threads. Das war einmal ein Peak der erreicht wurde. Natürlich Rendern die keine Filme. Normal sind ca. 30-50 Threads, wovon bis zu 10 zeitgleich laufen können (kommt drauf an was er macht). Und selbst die, die "laufen" warten meistens nur rum bis der FTP-Server antwortet.

Danke an alle....

Zitat von jaenicke:

Deshalb rate ich stattdessen dringend zu einer sauberen Lösung. ... Einfach den Thread nicht suspended starten...

Oder FreeOnTerminate nicht verwenden.

Also, prinzipiell sollte man im Thread immer nur mit PostMessage arbeiten.

Mal so ganz ins blaue geraten: Du sendest den Text mit WM_COPYDATA - und das ist nicht Thread-geeignet.

Ein bisserl mehr Quellcode wäre nett, dann könnte man vielleicht auch eine gescheite Aussage treffen und dir leichter weiterhelfen. Mit der Kristallkugel ist's am Wochenende nix, da ist die konsequent auf Urlaub...

Gruß
Luggi