Re: FreeAndNil nebenläufig

Markus Springweiler schrieb:

Der Zusammenhang zwischen ProcessMessages und TThread.Synchronize
ist mir jetzt grade nicht ganz klar.

Wenn du innerhalb von Code, den du via TThread.Synchronize aufrufst,
irgendwo ein ProcessMessages verbaut hast, dann friert im besten Fall
nur der Thread, oder auch zusätzlich der GUI-Thread ein.

Ich argumentiere, dass man in dem Moment, an dem das Programm seinen
Speicher freigibt, besser keine Threads einsetzen sollte, sondern
ausnahmsweise auf ProcessMessages zugreifen darf. Und du wiedersprichst
mir, indem du sagst, dass Threads schwer zu debuggen sind und man sich
damit sehr leicht in den Fuß schießt.

Fühlt sich an, als wolltest du mir zustimmen.

Und mit ProcessMessages alleine habe ich Schwierigkeiten, einen
Deadlock zu basteln.

Nichts ist unmöglich ;-) -- aber man baut schnell alle Möglichen
unsinnigen Konstrukte, um der Reentranz zu begegnen; das schenkt sich
zu Multithreading auch nicht mehr viel.

Du must der Reentranz ohnehin geeignet begegnen. Noch nie einen User
gehabt, der immer alles (auch den Start-Knopf) mit Doppelklick bedient
hat?

Ich bleibe dabei: in dieser Situation sollte man keine Threads
einsetzen und ein ProcessMessages ist angemessen.

MfG,
Sven.
--
Wo ist einklich Marian?

.

Relevant Pages

  • Re: Memo wird nicht gelöscht
    ... Ein ProcessMessages könnte ja später eh immer mal wieder vorkommen ... Sowas kommt beim Kunden besonders selten gut an. ... bzw. mit weiteren Zustandsvariablen in den Griff zu bekommen. ... Wiedereitritt/aufruf bei Threads genau so absichern. ...
    (de.comp.lang.delphi.misc)
  • Re: Refresh eines Objektes, aber wie?
    ... Die dann erst beim nächsten ProcessMessages abgearbeitet wird. ... Der Main Thread hat in diesem Fall ja nichts anderes zu tun, als Messages zu verarbeiten. ... Wenn die anderen Threads keine höhere Priorität haben, kommt er also ziemlich bald dran. ...
    (de.comp.lang.delphi.misc)