🚀 go-pugleaf

"Paul at NCF" <notplmacca@clara.co.uk> wrote in message 
news:45dd557c$1@newsgroups.borland.com...
>
>
> Does MainForm need to know about the command list or its workings?  You 
> can make the threadlist a member of the thread, not the form, add a 
> AddCommand(SctpCmdParams)  method to the thread which does 
> SctpCommandList->Add(SctpCmdParams), or go one step further and make the 
> parameters of that method the fields you need to pass to the thread that 
> need adding to 'its' queue.  That way you can change the entire queuing 
> system in the thread and the main form would not know or be affected.

Wouldn't that defeat the purpose?  In order for the queue to protect the two 
threads from each other, it needs to bridge the gap between the two.  If my 
thread puts the message into the queue itself, and then later takes it off, 
then what's the queue there for?


> >    SctpCommandList->Add(SctpCmdParams);
> >    sctpThread->HandleCommand();
>
> I don't think this helps your performance or queuing.  This adds the 
> command to the list in the MainForms scope, and also does the operation of 
> processing the queue in the main forms scope.

That looks to me like it adds the command in the main form, but then calls 
the sctp thread to handle it.

> the main form needs to add and then signal the thread.

Isn't that just what it's doing here?  The first line above adds the 
command, then the second line tells the thread there's a command for it to 
handle.


> The HandleCommand needs to be done via the threads execute method to make 
> the thread do the work,

> If you want to get the principle of the queue processing working initially 
> you can just get the thread execute to Sleep(10ms) and then check if the 
> queue is non-empty in its while loop.

I don't want the thread to sleep, because some of the applications I use 
this for may be handling high traffic volumes, and I don't want to slow down 
performance by blocking the communication library.  The while loop in the 
thread's Execute function looks like this right now:

    while (! Terminated ) {
     if (sctp_eventLoop() < 0)
       break ;
    }

If I could easily check whether there's anything in the queue, then maybe I 
could add a line here (so that it alternates with the library's 
sctp_eventLoop function) to check for any commands it has pending.  However, 
even seeing whether the TThreadList is empty or not requires locking it 
first.  If this thread keeps continually locking the list (even when there's 
nothing there), would the main thread have a harder time getting its own 
lock when it wants to add something?  I prefer for the main unit to tell the 
thread when there's a command in the list for it to handle.  That way, the 
thread would only need to lock the list when it's retrieving a command off 
of it.