[fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64

[Benedikt Schindler]

> 
>> - FreeOnTerminate should be gone, (meaning no way to actively call
>>  TThread.Destroy from another thread, a thread gets destroyed
>>  automatically when it leaves its execute method)
>>  (IIRC FreeOnTerminate was even set to False by the default
>>   constructor, so you had the choice of either using the default
>>   or introducing a race condition by setting it after the
>>   "inherited Create" - which starts the execute.)
> 
> This problem has been solved with http://bugs.freepascal.org/view.php?id=16884
> 
> 
> Jonas_______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> 

i don't agree with always FreeOnTerminate.
I have many prgramms that want to know the last status of the thread
before they free it.

But i think also the "bug" report you are linking to, shouldn't be a fpc
bug. It is more a programmer bug. As programmer i have to know at which
time i call the create methode of my TThread. So the correct programming
would be:

constructor TAThread.SomeCreate(aSuspended : boolean);
begin
  [... do my things here ...]

  inherited create(aSuspended);
end;

or

constructor TAThread.SomeCreate(aSuspended : boolean);
begin
  inherited create(True);

  [... do my things here ...]

  if not aSuspended  then Resume;
end;


I don't think fpc should slow down the thread creating, just to resolve
problems of not good thread programming of the fpc users.

When someone starts to programm threads, he has to know what he is doing.


cu all
Beni