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

[Michael Van Canneyt]

On Sat, 16 Oct 2010, Andrew Brunner wrote:

> On Sat, Oct 16, 2010 at 7:04 AM, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:
>
>> He cannot. If freeonterminate=true, then even if you call "inherited
>> create(false)" as the very last statement of your constructor, the thread
>> may already have finished running and freed itself before AfterConstruction
>> is called. The AfterConstruction call will then crash.
>
>
> Right.  I think that it would have been totally acceptable due to the
> nature of threads especially on differing os(es) to not have
> AfterConstruction because of this very issue.
>
> The fact that threads can zip through their execute event and self
> terminate before the AfterConstruction is even called is definitely an
> issue that can only be solved with synchronization of some sort.
> Threads are a special case where these objects themselves represent a
> kernel process with its own distinct timeline.  Logically, performance
> cannot be a priority when requiring synchronization of differing
> timelines.
>
> But for small projects where Delphi offers TThread with these
> features, it is good for FPC to accommodate Delphi source.  There is
> always going to be a demographic  who will never need performance and
> performance is not much of an issue for projects with < 1000 threads
> to the observer.
>
> IMO, it would be better to leverage the present performance condition
> to muster support for a high performance thread component set.

How about creating

a) A native TThreadManager record in system unit for unices.

b) Create a alternative thread class (TFPThread, TRTLThread, TFastThread or whatever)
    that uses the TThreadManager record to create 'Fast' threads, which
    would not be encumbered by the Delphi heritage of TThread.

Michael.