On Fri, Oct 15, 2010 at 10:57 AM, Vinzent Höfler <jellyfish.softw...@gmx.net> wrote:
> If you access it inside the execute method, you more or > less crash (or at least leak memory). You obviously had a problem with access ThreadID before it was assigned. Accessing it should not arrive at a RAV. I'm not sure this is on topic... > It took me a couple of days to find the reason for our application > crashing and I believe that was fixed quite a while ago. (Somewhere > around 2.0.4, IIRC). Jonas may remember. > Excerpt from the workaround I had written then: > //-- Overwritten to ensure it starts in suspended state, woken up > //-- by @link(AfterConstruction) a little moment later. > constructor Create; Exactly. It was poor implementation. You should have had a global barrier onExecute. That would unlock the thread after everything you needed was readable. See my project attached a few emails back. It demonstrates how things should be done with threads. Now - fpc carries one private barrier per thread instance. Developers of FPC should not always blame the development platform. They are sometimes going to need to redirect an issue back onto the developer. But I do recognize this is a delicate issue. But slowing us all down for issues such as these... Perhaps a wiki article on how to get threads to wait during execute would have an easier fix. And I'm sure a 100 people too would have problems. But I make a case, that slowing down the entire platform for those who need help getting threads to synchronize makes for a poor movement collectively. Perhaps a plethora of examples could help. > A similar workaround got into FPC a while later and it *was* for a > good reason: Safety. Anyone can make safety an issue. IMO, cThreads has a lot of RFI. (Room for improvement). >> There is no need to block the thread from execution. > > Actually there currently is. Otherwise you ask for trouble. I disagree. Completely. But that's just because I'm not tied to any one way of thinking. >> 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. > > What do you want to tie into there? I reviewed the pthreads code. BTW: pthreads is what FPC uses to implement threading. The barrier may be accessible therby eliminating the need for an additional instance being created inside TThread. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal