Am Fr., 14. Dez. 2018, 11:23 hat Michael Van Canneyt <mich...@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 < > mich...@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 >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal