🚀 go-pugleaf

"Vladimir Stefanovic" <antivari@po.sbb.co.yu> wrote in message
news:43456cbf@newsgroups.borland.com...

> I'm using Indy that was shipped with BCB6

Then you are using Indy 8, which is an outdated version that is no longer
supported.  Please go to Indy's website (http://www.indyproject.org) and
upgrade to Indy 9 or 10.

> What am I doing wrong? I thought it's Indy 9!

No, it is not.  It is Indy 8.

> Why you are using LockList/UnlockList?

Because the Threads property is a TThreadList, which is a TList that is
protected by a critical section.  You have to lock the critical section in
order to access the TList for any reason.

> I thought that ONE 'Connect()' on client side triggers
> ONE 'OnExecute()' on server side...

Nope.  OnExecute is triggered in a loop inside of TIdTCPServer, ie:

    TIdPeerThread::Run()
    {
        //...
        while( !Stopped )
            OnExecute(this);
        //...
    }

You can use the TIdPeerThread's Connection property to know which client is
triggering the event handler at the time.

> But now, when I re-think, it's obvious that *cannot* be
> possible - that I say on client side:
>
>    WriteInteger()
>    WriteString()
>
> ...and expect that *only* ONE OnExecute() is trigered.

That is not what I meant.  Individual writing operations do not trigger
their own OnExecute events.  When the OnExecute event is triggered, you read
everything you need from it, and then exit.  The OnExecute is then looped,
waiting for you to read more data when ready.

> But is it true that ONE Write...() trigeres ONE OnExecute()?

No.

> Yes, I was aware of that... I just wanted to resolve major
> problems first...

Thread safety is a major problem.  You can deadlock or crash the server if
your code is not thread-safe.


Gambit