I don’t get where this comes from, but it’s not the first time I have read it. I find it much easier to use a few thread classes and separate a program up into parallel apps than to deal with blocking I/Os for example. I tend to use the QT threading libraries, they are just more complete than the standard ones, and have nice callback and wait functions etc.
Some stuff I have written would be hideous to use if I didn’t parallel it, and can’t think how I could do some things if I didn’t.
I was just thinking how could one of my importers use threading, and realized that it would be quite trivial:
At the moment it parses the source file, poking values into a class object until that ‘section’ of the source is complete, then it runs the import method on the class that writes itself to the blender scene. Just make the class object a sub class of the threading library of your choice, and instead of waiting for the import method to finish just start it running on it’s own and go back to parsing the source file. I’m wondering if this ‘harder to write’ thing is that there are so many people still writing essentially procedural programs, because OOP based stuff seems easy to thread like this.
Another thing I have noticed is that most of the tutorials I have seen to do with python and threading don’t deal with inter thread communication, and most of the time I fail to see a use in the real world for any of the example code they use.