"Gaspar" <noreply@noreply.com> wrote in message
news:45a01b20@newsgroups.borland.com...
> I have a TIdTCPClient that sends commands to a TIdCmdTCPServer.
> I have an additional thread that reads messages from server.
That model will only work if the reading thread is the one pocessing
all of the command responses. You cannot use SenCmd() with a reading
thread present (that is why you can't use TIdCmdTCPClient with
TIdCmdTCPServer).
> It is protected with a CriticalSection so as to not interfere with
SendCmd's results.
That is not good enough. What happens if the server sends a
non-response packet at the very moment you lock the CS to call
SendCmd(), before the server receives the command? SendCmd() would
end up receiving the extra packet before the real response packet can
be received, which will cause SendCmd() to fail.
> There are two problems with this implementation:
There is more than just 2.
> 1) The thread is busy-waiting.
Only when outside of ReadLn(). While ReadLn() is waiting for data,
the thread is not in a busy state.
> 2) SOME_TIMEOUT should be as small as possible to leave the critical
> section as soon as possible.
Your approach will not work in general.
> Is there anyway to use an INFINITE_TIMEOUT (to avoid busy-waiting)
> and "wake-up" the IOHandler from it's readln operation when the
section
> is needed?
Indy already uses infinite timeout by default. ReadLn() would enter
an efficient waiting state when no data is available for reading. But
because you also have SendCmd() to deal with, you can't utilize that
support properly. You should really re-think your overall design. It
is really difficult to mix synchronous and asynchronous packets
together. Use one or the other, not both.
Gambit
