"Dejan Petrovic" <dejanbng@removeThis.ztbclan.com> wrote in message
news:45907a93$1@newsgroups.borland.com...
> AContext.Connection.IOHandler.ReadStream(ms, -1, true);
You are still setting AReadUntilDisconnect to True.
> I though onExecute is synchronized
It is not. All of TIdTCPServer's events that provide access to a TIdContext
object (TIdPeerThread in earlier versions) run in the context of a worker
thread that is managing that object. That has always been the case in any
version of Indy.
> Because I writing data to same visual components there comming
> bad data, for example.
You must manually synchronize access to the main thread.
> Because onExecute is already in thread I should have option to call
> this own Synchronize method but can't find that.
Not directly, but it is technically possible. Though I do not recommend it,
as it bypasses Indy 10's threading model.
Basically, when the TIdTCPServer is using a TIdSchedulerOfThread-derived
class (TIdSchedulerOfThreadDefault or TIdSchedulerOfThreadPool) for its
Scheduler property, the TIdContext.Yarn property points to a TIdYarnOfThread
object, which has a Thread property.
Otherwise, look at the TIdSync and TIdNotify classes instead (which existed
in Indy 9 as well).
> Of course, I can implement receiving queue and to process incoming data
> from queue
That is not a bad idea to do. There are reasons for avoiding Synchronize()
when possible - possible deadlocks during shutdown, for instance.
> I am still not sure which one exception can throw when I trying
> to write data to same collection or array.
Why would you have to throw any exception at all? If you have multiple
threads accessing the collection/array, you should be locking access with a
synchronization object to begin with (mutex, semaphore, critical section,
etc).
Gambit
