>> You mean I need to rewrite my entire server?
>>
>> Oh no...
> Not that much.
>
> Poor solution - add a critical section acquire/release around the public
> string/array accesses so that your timer system can work safely.
Can you give an example code please? - just something basic that I could
research and expand upon!
BTW, I don't use a timer in the server - Only the client to force it to
read - Indy IdTCPClient doesn't have an OnExcute handler - The example I
have (Written by Jeremy Darling) uses a system timer to force IdTCPClient to
read.
> Better solution - don't use a timer at all. Wrap your communications, (ie
> string etc), in a class and use the PostMessageAPI to send a custom
> message
> containing the instance reference to a form message-handler.
Ok, now you lost me.. Any chance you can provide a sample?
> This is not only safe, but also has no avoidable latency and will have a
> better
> performance than any other secondary-thread>main-thread comms mechanism.
>
> Polling, with timers or any other mechanism, is not necessary for
> inter-thread comms and always adds latency and CPU waste.
Basically my TCP server uses the OnExecute to read incoming/reply as needed.
However each thread also has access to the main array of users etc which
apparently is not a good idea as the array can become corrupt due to thread
collision - I don't know how to get around this..
Client simply uses a TTimer to try reading. Of course TCPClient not being a
threaded component I don't need to worry much however I would be interested
in finding a more reliable way of reading using IdTCPClient rather than
using the timer (which currently is set to check every 100ms)
All help appreciated!
