Michael Van Canneyt wrote:
On Fri, 14 Dec 2018, el es wrote:
On 13/12/2018 22:23, Michael Van Canneyt wrote:
On Thu, 13 Dec 2018, Martin Frb wrote:
---- Besides, the documentation does not say that FreeOnTerminate
is limited to be used in the thread construction. Especially since
its effect is not due until "terminate"
For me this is a given.
Almost by definition, changing anything in a thread after the
constructor has returned, is dangerous. You should set up everything
in the constructor.
Then this TThread.FreeOnTerminate property should not really be public,
if it's only to be used in 'private' context of the constructor?
I think FreeOnTerminate should not even exist. IMO it should simply be
'True'.
This is where I strongly disagree, to me it should always be False,
because having things free up themselves at unpredictable times is a
recipe for disaster which already hit me badly.
For instance, if a thread is still running when a DLL unloads, you get
deadlocks. Of if a thread finishes after the memory manager has been
unloaded, you are in for a hellish shutdown.
All this leads me to believe that FreeOnTerminate should always be left
to False, even if I can understand it's usefulness in some very specific
cases.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
