Multi-Threading Interview Questions

Q1. What is multi-threading and why do desktop apps need it?

Multi-threading means an application runs more than one sequence of instructions at the same time, each sequence called a thread. Desktop apps need it because the main thread is responsible for drawing the screen and responding to input, so any long task (file I/O, image processing, network calls) that runs on the main thread freezes the UI until it finishes. Moving that work to a background thread keeps the interface responsive, which is what users experience as a "fast" app.

Q2. What is the difference between the main (UI) thread and a background thread?

The main thread, often called the UI thread or event thread, is the one thread that owns the window: it redraws pixels, dispatches clicks, and runs animation frames. A background thread is any other thread the application spawns to run work without blocking the UI. Most GUI frameworks (WinForms, Swing, Tkinter, Qt, Android) only allow the main thread to touch UI widgets, so background threads must marshal their results back to the main thread before updating anything on screen.

Q3. Why should you not update the UI directly from a background thread?

UI toolkits are not thread-safe: their internal data structures assume a single thread is modifying them, so touching a widget from a background thread can crash the app, corrupt the layout, or silently drop events. The standard fix is to marshal updates back to the main thread using the framework primitive for it: `Control.Invoke` in WinForms, `SwingUtilities.invokeLater` in Swing, `root.after` in Tkinter, `signal.emit` in Qt, or `runOnUiThread` on Android. The background thread computes the result, then posts a small callback to the UI thread to actually draw it.

Q4. When should you use a thread pool instead of creating threads manually?

Use a thread pool whenever you have more than a handful of tasks, recurring work, or work triggered by user actions you cannot predict. Threads are expensive: each one consumes memory for its stack and the OS caps how many can exist, so spawning a new thread per task scales badly. A pool reuses a small fixed number of worker threads (typically 2 to 4 for desktop apps, or `cores` for CPU-bound work), queues incoming tasks, and keeps resource use predictable even under bursts.