Hello

I have a problem and I think I know why. But want to see if anyone can
comment.

I have a Windows (GUI) program which connects to a server and receives
events from the server. I have a main thread which handles the windowing
and also submits commands to the server. The problem I think is that the
submitting of commands is done from the main (windowing) thread. The
submitting code uses WaitForSingleObject and just sits waiting for a
response after each command is submitted. The trouble is the code
intercepting commands from the server is also same windowing thread. so I
think that while main thread is in WaitForSingleObject (just waiting) the
receiving of messages from the server cannot happen.

Just to put it simply, my commands after being submitted wait for a response
from the server before progressing. But I get no response from the server
because the thread is stuck in WaitForSingleObject and so cannot receive any
messages from server.

So my question is how to re-engineer?

Is this about right?

A) main thread to handle windowing.
B) spin off a thread to submit commands to server.
C) spin off another thread to receive messages from server.

Angus

Angus wrote:
Your analysis is correct. You need to avoid blocking in the main
thread, both to keep the GUI alive and to remain ready to receive new
messages. You may or may not need additional threads, depending on how
you are communicating. If you are using winsock then you can set it up
to post messages to your main thread's message queue (so you don't have
to use blocking calls).

--
Scott McPhillips [VC++ MVP]

My code which waits is run from a separate thread from the normal main
windows thread. BUT, this separate thread uses a pointer back to the main
window thread. So even though the thread doing the waiting is a different
thread, because it has a pointer back to the main windows thread, is it
actually still working in the same thread as the main windows processing
thread?

Is my separately spun off thread then trying to run a function in the main
window thread?

Angus




"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:m_-dnROX2ZvPAl7YnZ2dnUVZ_oytnZ2d@comcast.com...

Angus wrote:
How is the pointer used? Using a pointer to access data does not change
what thread your code is executing in. All threads can access all data
within the process.

On the other hand, if the secondary thread is using the pointer to call
functions, those functions run in the calling thread.

I think you are looking for a way to communicate between threads without
blocking the GUI. In general, you want to avoid WaitFor... calls in the
GUI thread so it can continue processing messages. When the secondary
thread has results to communicate it can call PostMessage to pass a
message to the GUI thread.

--
Scott McPhillips [VC++ MVP]

In article <eq04es$rko$1$8300dec7@news.demon.co.uk>, nospam@gmail.com
says...

[ ... ]

The only WaitFor* function that you should normally use in a GUI thread
is MsgWaitForMultipleObjects. Ocassionally, if you're using a
PeekMessage loop it can make sense to combine it with a WaitFor* with a
timeout of 0 (or a few milliseconds) but that's fairly unusual.

[ ... ]

That's one way of doing things. A lot depends on whether you're trying
to optimize for simplicity or performance. I don't see a lot of reason
to dedicate a thread to sending commands to the server -- you can
usually do a send asynchronously so there's no need for a thread.
Waiting for messages from the server depends heavily on how you're going
to receive those messages -- depending on how you're doing things, you
can receive them as actual messages in your message loop, or see an
Event triggered, or whatever. If it shows up as a message, it's fairly
straightforward to handle that in your normal message loop. If its a
kernel object being signalled, you can either use a separate thread, or
(as mentioned above) MWFMO.

--
Later,
Jerry.

The universe is a figment of its own imagination.