obones at free.fr
Fri Dec 14 11:04:45 CET 2018
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
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
More information about the fpc-pascal