[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