I have a design question for you all. At this point, I'm trying to lay out how I plan to implement threads in my chat client. How are you all handling threads for the socket connection and for the UI/inputs? Below is how I plan to implement it. Could someone look this over and tell me wether this design is ok or give any advice? Thanks.

I plan to have 2 main classes/objects. A chatclient class (using ncurses) and a connection class (using sockets). There will be 2 queues, one for all the recvs, and one for the sends.

The chatclient class will have 2 threads:

1 thread for user inputs (chat sends, scrolling, etc.) It will also enqueue the chat sends to the connection class's send queue.

1 thread for updating the screen (chat window, userlist, channel name, etc.) It will dequeue from the connection class's recv queue.

The connection class will have 2 threads:

1 thread for recv (blocking i believe). Once it recvs something from bnet it will enqueue the event on the recv queue.

1 thread for sending. It checks the send queue, and dequeues to send if there is something on the queue.


All these threads will be in a loop to handle their appropriate purpose. Is this efficient? I am afraid that a thread will hog the CPU while doing essentially nothing. (The thread for sending?)

Any ideas on how everyone else designed their chat client/bot would be helpful. Thanks.

I forgot to mention I'm programming on g++ in Linux. :)

If you're using a blocking recv (ie, it waits till it gets data before continuing) you should be ok.

I don't know anything about how ncurses works, but in Java gui's have their own thread which waits for you to click something. This is probably the same idea as ncurses - ie, it won't eat cpu time until you do something.

I think there would still have a need for 2 threads no matter what gui you're using. A thread to update the screen/window if the user does nothing, and a thread to update the screen/window if the user does something.

I'm not entirely sure how the normal api's work. All I know is Java only has 1 (user-visible) thread for the gui, which is the event dispatcher.

I would suggest not using blocking sockets, but rather doing a select() on it. You can lose a thread or two, and its not much harder to code than a blocking socket.

I don't know ncurses - does it always require a dedicated thread?

In many recent bots there is just a single thread doing everything. All you have to do for that to work is using nonblocking socket calls.

I'd use one thread for everything.

Meh, I am lucky, .NET uses implicit threading on event callbacks, and for the rest, I run several threads otherwise -- one maintaining the queues, one maintaining the message display.

[quote author=Adron link=board=17;threadid=6180;start=0#msg53758 date=1081286909]
I don't know ncurses - does it always require a dedicated thread?

In many recent bots there is just a single thread doing everything. All you have to do for that to work is using nonblocking socket calls.
[/quote]
Ncurses is like any other UI (though text-based). It requires at least one thread, which can be the main thread.

For a bot, yes, it is very possible to do everything in one thread. It is just handling each message or event as you get it.

For a chat client, it is also possible, but I think it is much cleaner to have at least two threads. One to handle the GUI processes and one to handle the connection.
----

In my situation, I suppose I can combine the 2 threads in the connection class to be just one.

For my chatclient class (UI), I may stick with two threads. I intend to have the setup similiar to how it is in starcraft, with a input window, a users-in-channel window and a chat text window. I plan the user to switch between each window to gain usage of each one. For example, the user would have to 'select' (F1 or some other special key) the chat text window in order to scroll (with up and down arrows of course).

The thing is, at the same time as handling all the user inputs, I would need to update the GUI with bnet connection events. Hence my reasoning on using two threads for the chatclient class. I would get two threads, each doing a clear set task, instead of one bigger thread switching between
1. parsing user key inputs for UI actions and
2. Checking a queue for new bnet events (with mutex locking) which could or could not lead to a separate UI action.


What are your thoughts? Perhaps my design is more convoluted then it needs to be.

I think it is a simple design explained in a complex way. If you understand threads, then by all means use them. I am no expert but from what I have read, with today’s technology if properly used they can be very beneficial.

My bot has one thread that handles incoming/outgoing data, filters, remote commands, channel list, etc... This thread will be the only thread running unless the user wants to chat. If the user wants to be in chat mode, it launches a separate thread that handles the chat interface and registers itself to receive events from main bot thread. In java, as Iago pointed out, the UI is on its own thread and issues events.

Edit: spelling