🚀 go-pugleaf

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:vj8nt2llf7deda6ioqggci4rds885qcmne@4ax.com...
>
> I see that you are also concerned about the Thread falling behind
> the application, and getting messages out of order. One way out
> is to add a ring buffer.
> The application stuffs data into the head of the ring, then tells
> the thread that new data is available. (Once again, the data is
> now in an escrow buffer, so the application data can change or
> "go away".) The thread takes data off the tail of the ring, and
> sends it.

This sounds like the queue approach that Paul was talking about.  I've 
looked at TThreadList, and think I can use that for a queue of commands I 
want the thread to process.  Here's how that looks so far:

In the header, I defined a structure to hold commands and their parameters. 
It looks like this:

   enum TSctpCommand { scmdConnect, scmdShutDown, scmdSend };

   typedef struct SctpCmdParamRec {
      TSctpCommand Command;
      unsigned char MsgBuffer[MAX_BUFFER_LENGTH];
      int MsgLen;
      unsigned int AssocID;
      unsigned char DestAddr[SCTP_MAX_IP_LEN];
      unsigned short DestPort;
      int SiteIndex;
   } TSctpCmdParams;


Then I have:
   TThreadList* SctpCommandList;
defined globally in my main unit (and extern in the thread unit), which gets 
instantiated with 'new' in my main form's constructor.

Whenever the main form wants to initiate something in the SCTP thread, it 
does something like this:

// --------------------------------------------------------------
void __fastcall TForm1::Send(String Message, int Site)
{
   if (sctpThread) {
      TSctpCmdParams *SctpCmdParams = new TSctpCmdParams;

             SctpCmdParams->Command   = scmdSend;
             SctpCmdParams->AssocID   = associationID[Site];
      strcpy(SctpCmdParams->MsgBuffer,  Message.c_str());
             SctpCmdParams->MsgLen    = Message.Length();

      SctpCommandList->Add(SctpCmdParams);
      sctpThread->HandleCommand();

   } else
      Memo1->Lines->Add("ERROR: sctp Thread does not exist");
}
// --------------------------------------------------------------

(The Connect and Disconnect functions in the main form look almost identical 
to this except that they set different members of SctpCmdParams.)

In the SCTP Thread unit, anything coming from the VCL Thread will enter via 
this function:

// --------------------------------------------------------------
void TsctpThread::HandleCommand(void)
{
   TList* CmdList;
   TSctpCmdParams* SctpCmdParams = NULL;

   CmdList = SctpCommandList->LockList();
   if (CmdList->Count > 0) {
      SctpCmdParams = (TSctpCmdParams*)CmdList->First();
      CmdList->Remove(SctpCmdParams);
   }
   SctpCommandList->UnlockList();

   if (SctpCmdParams) {
      switch (SctpCmdParams->Command) {
         case scmdConnect:
                  Connect(SctpCmdParams->DestAddr,
                          SctpCmdParams->DestPort,
                          SctpCmdParams->SiteIndex);
                  break;
         case scmdShutDown:
                  ShutDown(SctpCmdParams->AssocID);
                  break;
         case scmdSend:
                  Send(SctpCmdParams->MsgBuffer,
                       SctpCmdParams->MsgLen,
                       SctpCmdParams->AssocID);
                  break;
      }
      delete SctpCmdParams;
   }
   // should probably add an 'else' here for an error message
}
// --------------------------------------------------------------

This does have the VCL thread allocating structures which the SCTP thread 
eventually deletes, but I think that should work so long as the TThreadList 
buffers the two accesses adequately.  The VCL thread never looks at the 
SctpCmdParams it created again after putting it on the TThreadList, and the 
SCTP thread uses and deletes it after getting it off of that list.

There is a bit of overhead in my TSctpCmdParams structure, because space for 
all possible parameters gets allocated each time, even though only the 
parameters relevant to that particular command get used.  I'm not too 
worried about that, though, because by far the largest piece of it is the 
MsgBuffer, and that's what I'm going to need the most often anyway.  (The 
Send command is the one that can get called a lot.  Connect and ShutDown 
commands, where that MsgBuffer is unnecessary, are infrequent events.)