threading

[Chris Angelico]

On Thu, Apr 10, 2014 at 3:31 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Really, the threading model is only good for a relatively small subset
> of programming objectives, and over the lifetime of the solution, you
> will often come to realize threading wasn't that good a fit after all.
> Namely, in any given state, you will have to be prepared to handle more
> than one stimulus. Also, over time you will learn to dread the race
> conditions that are endemic in thread programming. Those are the kinds
> of problems that make you check out the current job postings. Only
> there's no escape: in your next job, they are going to make you find and
> fix the race conditions in your predecessor's code.

People with a fear of threaded programming almost certainly never grew
up on OS/2. :) I learned about GUI programming thus: Write your
synchronous message handler to guarantee that it will return in an
absolute maximum of 0.1s, preferably a lot less. If you have any sort
of heavy processing to do, spin off a thread. It was simply the normal
way to do things. Normal handling was done on Thread 0, and two
sequential events would be processed sequentially on that thread (so
if your handler for the Enter keypress message clears out an entry
field, the next key pressed is guaranteed to happen on an empty
field), and everything else, it's considered normal to spawn threads
and let them run to completion.

ChrisA