Controlling the work of worker threads via the main thread...

Question

Hey I am not sure if this has already been asked that way. (I didn´t find anwsers to this specific questions, at least). But:

I have a program, which - at startup - creates an Login-window in a new UI-Thread.

In this window the user can enter data which has to be verified by an server. Because the window shall still be responsive to the users actions, it (ofc it´s only a UI-thread) shall not handle the transmission and evaluation in it´s own thread. I want the UI-thread to delegate this work back to the main thread.

In addition: The main thread (My "client" thread) shall manage all actions that go on, like logging in, handle received messages from the server etc... (not window messages)

But I am not sure of how to do this: 1.) Shall I let the UI-Thread Queue an APC to the main thread (but then the main thread does not know about the stuff going on. 2.) May I better use event objects to be waited on and queues to transmit the data from one thread to another?...

Or are there way better options?

For example: I start the client: 1. The client loads data from a file and does some intialization

1. The client creates a window in a new thread which handles login data input from the user.

2. The Window Thread shall notifiy and handle the , that has been entered by the user, over to the client.

3. The Client shall now pack the data and delegate the sending work to another object (e.g. CSingleConnection) which handles sending the data over a network (of course this does not require a new thread, because it can be handle with Overlapped I/O...

4. One special receiver thread receives the data from the server and handles it back to the client, which - in turn - evaluates the data.

5. If the data was correct and some special stuff was received from the server, the main thread shall signal the UI thread to close the window and terminate...

6. The client then creates a new window, which will handle the chatting-UI

7. The chatting UI thread and the Client thread shall communicate to handle messages to be sent and received...

(Hope this helps to get what I am trying)...

Answer 1

It all depends on what you are prepared to use. If you are developing with Qt, their signals and slots are just the thing to do such a communication. They also supply a network library, so you could easily omit the receiver thread because their network classes do asynchronous communication and will send a signal when you have data, which means your thread does not need to be blocked in the mean time.

If you don't want to use Qt, boost also supplies thread safe signals and slots, but as far as I understand it their slots will be run in the context of the calling thread...

Anyways, I have used Qt sig and slots with great satisfaction for exactly this purpose. I wholeheartedly agree GUI's shouldn't freeze, ever.

Answer 2

I don´t know wether this is good style or not (anwsering Your own question):

But I think I go with Event Objects and two queues (one for the connection between Client and Connection, and one to communicate Client and UI)...