[fpc-pascal] TThread.FreeOnTerminate

[Sven Barth]

Am Fr., 14. Dez. 2018, 11:23 hat Michael Van Canneyt <michael at freepascal.org>
geschrieben:

>
>
> On Fri, 14 Dec 2018, Sven Barth via fpc-pascal wrote:
>
> > Am Fr., 14. Dez. 2018, 10:31 hat Michael Van Canneyt <
> michael at freepascal.org>
> > geschrieben:
> >
> >>
> >>
> >> 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'.
> >>
> >
> > I disagree, because then you could never do a WaitFor(). Or provide the
> > thread with new data through a method (that fills a queue that the thread
> > processes) without risking an access violation.
>
> This can be solved with the OnTerminate event. As long as you didn't get
> that, the thread is still alive.
>

That won't help if multiple threads are involved, because OnTerminate will
always arrive on the main thread and a thread using the just terminated
thread might be in the middle of a method call to that thread.

Also the argument regarding WaitFor still stands.

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20181214/0dabf60c/attachment.html>