Thread Programming Basics

Imagine two people chatting through a program. In a simple command-line version, one person types a line, the line travels across the network, and then that person sits and waits until the other side replies before typing again. The conversation moves in strict turns. That rhythm is fine for a basic demonstration, but it does not match how people actually talk through a messaging window, where a message can arrive at any moment and you may want to keep typing while it does.

GUIChat is the first example in this part of the course that uses threads to handle network communication. Its design lets a user keep sending messages without waiting for a response, while incoming messages still appear as soon as they show up. This article follows that design from the top down: first the two threads that make it possible, then the client and server roles, and finally what the program's structure means for the person running it.

GUIChat is an asynchronous chat program. A user can send messages without waiting for a response, and incoming messages are displayed as soon as they arrive. The key word is asynchronous: sending and receiving are not locked into a fixed order where one must finish before the other begins.

GUIChat splits its work between two threads, and each has a clearly different job. The first is a message-reading thread. Its only task is to receive messages from the other side of the connection. When a message arrives, this thread displays it to the user. Then it blocks, meaning it pauses and waits, until the next message arrives.

The second is the event-handling thread. This thread responds to user actions such as clicks and key presses. When the user presses return in the input box, this thread is the one that sends the typed message out over the connection.

The important consequence is that blocking in one thread does not stop the other. The reading thread can sit idle for a long time, while the event-handling thread keeps running, ready to send a message the moment the user produces one. This separation is what makes the exchange asynchronous: sending and receiving are not tied to each other in a fixed order.

The diagram below shows the two independent paths. The outgoing path starts with a user action and ends at the connection. The incoming path starts when a message arrives from the other side and ends in the transcript. The two paths do not have to take turns, which is why a user can type while a reply is on its way.

The sequence below follows a moment when the user sends a message while another message is still arriving. The diagram emphasizes that the sender is not waiting for a reply before continuing, and that the reading side is blocked only until the next message arrives.

A connection needs two ends, and GUIChat can fill either one. The program is not locked into a single role. Its interface has a Listen on port button and a Connect button, and the choice between them determines which end the window plays.

When a user clicks Listen on port, the GUIChat window creates a server socket that waits for an incoming connection request, so that window acts as the server. The server listens on a specified port number. When a user clicks Connect, the window sends a connection request, so it acts as the client. The client must know two things to reach the server: the computer on which the server is running and the port on which the server is listening. GUIChat provides input boxes where the user enters that information.

Once the connection is established, the distinction between the two roles matters only for setting up the link. Both windows then exchange messages through the same threading design described earlier, so the chat behaves the same regardless of which side started the connection.