On Fri, Oct 15, 2010 at 9:24 AM, Michael Van Canneyt <mich...@freepascal.org> wrote: > > Thank you, > > I'll study it to see if/how we can do something to increase speed of > creating threads > in FPC. > > But if I understand you correctly, the WRITE_MEMORY_BARRIER() call is > beyond our reach, so there's little we can do about that. > > Michael. >
Thanks for all your help too! I'm just wanting a really stable program executable. My goal is to make sure FPC is stable and fast as possible under Linux. So any "tire kicking" I do is for the benefit of FPC - nothing else. It was also suggested that PThread's Suspend and Resume may not do anything. What I would do (if that is the case), is try to find where PThread has access to the Semaphore or CriticalSection it has on that thread... If you could tie into that system, you would be able to not have that extra inefficiency of the FPC Semaphore (and any the creator of TThread may have). All these barriers add serious inline time. IMO. You must assume that all variables of the TThread descendant have already been assigned and are valid. There is no need to block the thread from execution. That is unless they are asking to have it suspended on creation. And if that is the case... We need to tie into PThread's Semaphore or Event or CriticalSection and exploit that. It's going to lead to a really significant gain for TThread.Create. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal