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. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
