On Sat, 16 Oct 2010, Andrew Brunner wrote:
On Sat, Oct 16, 2010 at 7:04 AM, Jonas Maebe <jonas.ma...@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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
