3. Work on a task handled by a thread pool, like scalable software
4. Work on another process, like safe software
Even 20 years ago single threading was well known to be inadequate – anyone doing file or network I/O got daily reminders of how bad that was as the UI wedged, not to mention MacOS where holding a menu open froze an app.
Windows NT, OS/2, and BeOS were better, if only the hardware cost cane down and we could ditch this legacy DOS/Win16 code…
Nowadays, a great many GUI apps have a lot of data crunching to do in the background. You've really got two options for how to handle that:
(Intentionally omitting the option of breaking your work into a bunch of tiny bits that can be handled on a single thread's event queue like some sort of deranged node.js app from hell, on the grounds that please no I can't even.)