🚀 go-pugleaf

Hi,

I may have lost the plot, but I thought you wanted to pass information to a 
(secondary) thread from the main VCL thread (mainform)?

> 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?

If you call the threads AddCommand method to add to the queue, the main VCL 
thread is running and calling into the thread.  So the VCL thread is adding 
to the queue.  The thread could then get signaled and woken up, and remove 
the item off the queue.

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

Yes, thats what the example looked like that you showed?

> 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.

Not sure it did.  Looked to me like the VCL thread added the command to the 
queue, and then calls the threads handle command to take it off the queue 
and process it?

> 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:

Yes, I wouldn't do that normally, I was suggesting it to get something 
basically working without setting up the signalling and wait for objects 
API.

> 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.

WaitForMultipleObjects would only wake up the thread when something was 
signalled.  And it would only block the VCL thread when it was locked, and 
vv.

As I said, I may have lost the plot and be completely misunderstanding what 
you are trying to do.

Paul