[fpc-pascal] TThread.FreeOnTerminate

Michael Van Canneyt michael at freepascal.org
Fri Dec 14 11:08:34 CET 2018



On Fri, 14 Dec 2018, OBones wrote:

> 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.

The opposite problem is just as bad: you cannot guarantee that you can shut
down a thread properly, because you have no idea of the state it is on.

>
> 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.

And now we have come to the root of the problem:

Threads are unpredictable, and hence evil in programming :-)

Michael.



More information about the fpc-pascal mailing list