On Thu, Apr 10, 2014 at 3:31 AM, Marko Rauhamaa <ma...@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 -- https://mail.python.org/mailman/listinfo/python-list
