Hello Benito,
>>From: Benito van der Zander
>>
>> I know you are coding in Lazarus - but Lazarus - even simplified adds
>> layers of stuff - is there anyway you can make your core functionality
>> reside in a UNIT - and then make a console app test application that
>> puts it through its paces.... then if it works - link it in to your
>> "Lazarus GUI in Development" ?
>>
>I made another test program, in console mode with critical sections,
>but it still happens (but not so often).
You know - I just emailed Wily Dev recently because his comments about
my debug code inspired me to look for this intermittent issue I was
having... and all I did to resolve it was grep -n "assign(" *.pp
and make sure each file IO I had that was potentially going to be used
by my threading code was converted to use my home grown threadsafe
fileio unit. (Which manages the freepascal FileMode global flag and also
maintains opened files and their mode - so I can force serialization
when there is contention...)... anyway..
that seems to have resolved all the quirks from my webserver/application
server. There were only two instances of file IO I overlooked - which
made it all the more random...
I only mention this so you think about it and either get reminded of
something in yourode YOU want to double check - or if you've done all
this.. just read it, dismiss ...move on. :)
>It should be attached
Saw it.
>> I also see potential issue here:
>>
>> Begin ---- Snippet
>> procedure TForm1.testTerminate(Sender: TObject);
>> begin
>> if (sender is ttestthread) then
>> memo1.lines.add(ttestthread(sender).result);
>> end;
>> End ---- Snippet
>>
>This shouldn't be problematic, because onTerminate
>is guaranteed to be called in the main thread
And you're absolutely sure that the memol object isn't being accessed by
more than one thread? If so: Great.
>
>However, perhaps it doesn't have to do anything with threads,
>but with network load, because the transmission also fails
>sometimes, if I start several single-threaded processes.
>Perhaps the connect timeout is too low?
That's something I imagine you can dig into and change with a constant
or some configuration mechanism... so I'll let that be... but I will say
that having some sort of means to track where your threads are getting
to - whether via individual log files, which WilyDev reminds us can
change the thread timing considerably, or like I also do - a memory
based log inside each thread. The tricky part is making sure you have a
way you can "drill into" each thread and interrogate where it is. I did
this with a Double Linked List.. I protect the list by wrapping in
critical section bit - and have that same critical section object
available in my main program so it can safely access each thread's
"log". all I do it list out on the screen the DBIN results. Note that I
have mating DBOUT calls that remove items from the list as well.. one
might say its a cheap "extra call stack" ... but at least I know where
they fail... or at least the last point they reached before I lost them.
I only bring this technique up again because if you don't exactly where
they are failing... Maybe you do already, but without that - your kind
of grasping at straws. Just like when Wily Dev said that once your call
goes into someone elses library - you're in the dark on threading
because you likely don't have a clue whats going on in r "blackbox".
I don't have much else to offer here but I wanted to give you a response
:)
All the best...
Jason
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
synalist-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/synalist-public
