[Chicago] desktop development

[Bryan Oakley]

On Fri, Dec 3, 2010 at 7:50 PM, Tal Liron <tal.liron at threecrickets.com> wrote:
> Any GUI that needs to run "something" in the background would need an extra
> thread, if you want to keep the app responsive and have a good user
> experience (asynchronous notifications, progress bars, etc.)

That's not necessarily true. All GUIs have an event loop that is
typically 90%+ idle. All those idle cycles can be used to do
processing. If you take the time to divide up your work into small
chunks you can easily do that work when the main thread is otherwise
idle. Progress bars and asynchronous I/O are perfect cases for that
(except in performance critical operations, of course).

It's also possible (and IMHO more desireable) to push this heavy
lifting into a separate process. That to me is a better solution than
threads because separate processes are less complex than multiple
threads. And in this day and age (certainly not true a dozen years
ago!) the overhead of spawning another process is negligible.

Sometimes, yes, a second thread is useful. I don't dispute that
sometimes they are necessary. I just don't agree they are always
necessary. Obviously, YMMV. To me, multiple threads are like modal
dialog boxes: they should be avoided like the plague, but sometimes
they are the exact right tool for the job.