TIdTCPServer OnExecute not fired for some messages unless mouse in window - c++builder

Question

We have a Windows app that we're adding a socket interface for remote configuration and data processing. A TIdTCPServer object receives the messages in the OnExecute event. For some messages, however, the OnExecute event is not fired unless the cursor is moved in the main window.
UPDATE: With a lot more experimenting, whether or not the message is processed immediately, or after a long pause, or not at all, seems more random. In all cases, moving the cursor causes the message to be processed immediately. However, it doesn't seem to be specific to a message, or the order of messages.
Updated source code listings: Here's the OnExecute handler:
void __fastcall TSigToolForm::IdTCPServer1Execute(TIdContext *AContext)
{
TIdBytes buffer;
if (ReceiveBuffer(AContext, buffer))
{
try
{
try
{
msg = &buffer[0]; // msg is class member
TThread::Synchronize(0, mProcess); // Doesn't return until mProcess finishes
buffer = IPOK().toByteArray(); // Ack
SendBuffer(AContext, buffer);
}
catch (const std::exception & ex)
{
buffer = IPFailCommand(ex.what()).toByteArray();
SendBuffer(AContext, buffer);
}
catch (const Exception & ex)
{
buffer = IPFailCommand(toStdString(ex.Message)).toByteArray();
SendBuffer(AContext, buffer);
}
catch (const EIdException & ex)
{
throw; // Let Indy have it
}
}
__finally
{
msg = 0;
}
}
}
The mProcess function and the processMessage function it calls. I stripped all but one message type that processMessage handles:
void __fastcall TSigToolForm::mProcess()
{
if (msg) processMessage(msg);
}
void TSigToolForm::processMessage(byte * message)
{
CSLock lock(cs); // RAII class, cs is TCriticalSection
try
{
IPCommand cmd(message);
switch (cmd.ID)
{
case IPCommand::SET_CAD :
{
setObjectCad(cmd);
break;
}
}
}
catch(const std::exception & ex)
{
ShowMessage(ex.what());
}
catch (const EIdException & ex)
{
throw;
}
catch (...)
{
ShowMessage("Exception in processMessage");
}
}
The ReceiveBuffer and SendBuffer functions:
bool ReceiveBuffer(TIdTCPClient * aClient, TIdBytes & ABuffer)
{
return ReceiveBuffer(aClient->IOHandler, ABuffer);
}
bool ReceiveBuffer(TIdContext * AContext, TIdBytes & ABuffer)
{
return ReceiveBuffer(AContext->Connection->IOHandler, ABuffer);
}
bool ReceiveBuffer(TIdIOHandler * IO, TIdBytes & ABuffer)
{
CSLock lock(cs);
try
{
long sz = IO->ReadLongInt();
IO->ReadBytes(ABuffer, sz, false);
return true;
}
catch (const EIdException & ex)
{
throw;
}
return false;
}
bool SendBuffer(TIdIOHandler * IO, const TIdBytes & ABuffer)
{
CSLock lock(cs);
try
{
IO->WriteBufferOpen();
try
{
IO->Write(ABuffer.Length);
IO->Write(ABuffer);
IO->WriteBufferClose();
}
catch(const Exception &)
{
IO->WriteBufferCancel();
throw;
}
}
catch(const EIdException &)
{
throw;
}
catch (...)
{
return false;
}
return true;
}
bool SendBuffer(TIdContext * AContext, const TIdBytes & ABuffer)
{
return SendBuffer(AContext->Connection->IOHandler, ABuffer);
}
bool SendBuffer(TIdTCPClient * aClient, const TIdBytes & aBuffer)
{
return SendBuffer(aClient->IOHandler, aBuffer);
}
For testing I have a separate program that creates and send the various messages, using TIdTCPClient and the same send / receive buffer functions. This is the only connection to the server program. Here's an example:
void TForm16::setPortAndConnect()
{
IdTCPClient1->Port = bdePort->IntValue();
IdTCPClient1->Host = editHost->Text;
IdTCPClient1->Connect();
}
void TForm16::sendCommandToSVST(const TIdBytes & buffer)
{
try
{
setPortAndConnect();
if (SendBuffer(IdTCPClient1, buffer))
{
TIdBytes recv;
//
// Read the response
if (ReceiveBuffer(IdTCPClient1, recv))
{
IPCommand response = IPCommand::fromByteArray(recv);
}
}
}
__finally
{
IdTCPClient1->Disconnect();
}
}
bdePort is an internal TEdit-derived that deals with numerical input. I'm confident that the data itself is correct. It's getting the server to respond that is a problem right now.
I assume at this point that there must be something the program itself is doing that's interfering with the GUI thread or the socket connection or both. I know this is very open-ended, but any hints on what to look for would be appreciated.
This is C++Builder 10.1 update 1, using the classic compiler.

Answer 1

For some messages, however, the OnExecute event is not fired unless the cursor is moved in the main window.
TIdTCPServer is a multi-threaded component, the OnExecute event is fired in a worker thread in a continuous loop for the lifetime of the socket connection. So the ONLY way it could be getting blocked until mouse activity is detected is if your OnExecute code is synchronizing with the main UI thread, and the main UI thread is blocked until window messages are received.
In the code you have shown, the only places where your OnExecute code could be getting blocked are the calls to ReceiveBuffer(), mProcess(), and SendBuffer(). Make sure they are all thread-safe. You did not show the code for any of those methods, or the code for your main UI thread, but mProcess() is being called via TThread::Synchronize() so start with that one and make sure your main UI thread is not blocking mProcess() while it is trying to process a socket message.
BTW, you are catching only STL-based exceptions (derived from std::exception), but you are completely ignoring RTL-based exceptions (derived from System::Sysutils::Exception). And in the case of Indy-based exceptions (which are derived from EIdException, which itself is derived from System::Sysutils::Exception), DO NOT swallow them! If you catch an Indy exception, re-throw it and let TIdTCPServer handle it, otherwise its threads will not be able to detect socket disconnects and clean up properly (unless you manually call AContext->Connection->Disconnect() in your code).
Don't know the Indy version, whatever came with the compiler.
You can find out the Indy version by:
looking for Indy in the IDE's "About" box
right-clicking on any Indy component in the Form Designer at design-time.
reading the Version property of any Indy component at runtime.
UPDATE: Why are you using a critical section around everything? You don't need that.
You are reading/writing a client socket from only 1 thread (the one firing the OnExecute event). Even if you were reading in one thread and writing in another thread, that is safe to do with sockets without placing a lock around the IOHandler. So you don't need a lock around those IOHandler operations at all.
And your mProcess() method is already being serialized by TThread::Synchronize(), so it will only ever run in the main UI thread. If multiple client threads want to call mProcess() at the same time, Synchronize() ensures it runs only one at a time. So you don't need a lock for that, either. However, your use of ShowMessage() inside of mProcess() is problematic, because it runs a secondary message loop that will allow pending Synchronize() requests to run while mProcess() is still running, so you can end up with multiple mProcess() calls overlapping each other. You should not be doing anything inside of a synced method that can cause window messages to be processed. If a synced method throws an exception, you should not try to catch it. Synchronize() catches exceptions and rethrows them in the context of the thread that called Synchronize(), and you already have exception handlers in your OnExecute code.
The only place I see where you should be using any kind of lock, if any at all, would be inside of setObjectCad(), but only if it needs to access data that can be accessed by multiple threads at the same time.
With that said, try something more like this instead:
void ReceiveBuffer(TIdTCPClient * aClient, TIdBytes & ABuffer)
{
ReceiveBuffer(aClient->IOHandler, ABuffer);
}
bool ReceiveBuffer(TIdContext * AContext, TIdBytes & ABuffer)
{
ReceiveBuffer(AContext->Connection->IOHandler, ABuffer);
}
void ReceiveBuffer(TIdIOHandler * IO, TIdBytes & ABuffer)
{
long sz = IO->ReadLongInt();
IO->ReadBytes(ABuffer, sz, false);
}
void SendBuffer(TIdIOHandler * IO, const TIdBytes & ABuffer)
{
IO->WriteBufferOpen();
try
{
IO->Write(ABuffer.Length);
IO->Write(ABuffer);
IO->WriteBufferClose();
}
catch(const Exception &)
{
IO->WriteBufferCancel();
throw;
}
}
void SendBuffer(TIdContext * AContext, const TIdBytes & ABuffer)
{
SendBuffer(AContext->Connection->IOHandler, ABuffer);
}
void SendBuffer(TIdTCPClient * aClient, const TIdBytes & aBuffer)
{
SendBuffer(aClient->IOHandler, aBuffer);
}
void __fastcall TSigToolForm::IdTCPServer1Execute(TIdContext *AContext)
{
TIdBytes buffer;
ReceiveBuffer(AContext, buffer);
try
{
msg = &buffer[0]; // msg is class member
TThread::Synchronize(0, mProcess); // Doesn't return until mProcess finishes
buffer = IPOK().toByteArray(); // Ack
SendBuffer(AContext, buffer);
}
catch (const std::exception & ex)
{
buffer = IPFailCommand(ex.what()).toByteArray();
SendBuffer(AContext, buffer);
}
catch (const Exception & ex)
{
buffer = IPFailCommand(toStdString(ex.Message)).toByteArray();
SendBuffer(AContext, buffer);
if (dynamic_cast<const EIdException *>(&ex))
throw;
}
catch (...)
{
buffer = IPFailCommand("Unknown exception").toByteArray();
SendBuffer(AContext, buffer);
}
}
void __fastcall TSigToolForm::mProcess()
{
if (msg) processMessage(msg);
}
void TSigToolForm::processMessage(byte * message)
{
IPCommand cmd(message);
switch (cmd.ID)
{
case IPCommand::SET_CAD :
{
setObjectCad(cmd);
break;
}
}
}
void TSigToolForm::setObjectCad(const IPCommand &cmd)
{
// here is where you should be using CSLock, if at all...
}
void TForm16::setPortAndConnect()
{
IdTCPClient1->Port = bdePort->IntValue();
IdTCPClient1->Host = editHost->Text;
IdTCPClient1->Connect();
}
void TForm16::sendCommandToSVST(const TIdBytes & buffer)
{
setPortAndConnect();
try
{
// Send the command
SendBuffer(IdTCPClient1, buffer);
// Read the response
TIdBytes recv;
ReceiveBuffer(IdTCPClient1, recv);
IPCommand response = IPCommand::fromByteArray(recv);
}
__finally
{
IdTCPClient1->Disconnect();
}
}