While working on my research project/thesis, I decided that I really need to start incorporating threads into my apps to make anything of myself as a competent programmer. This involved two significant revelations: first, that pthreads do not inherently play nice with C++ OOP (duh! they're a native C library!); and second, threading OpenGL programs in an entirely different ball game.

Getting a thread up (which, for the record, I have done before for classroom projects), was no big deal. Then realizing that C++ classes don't play nice with pthreads was a bit tricky. Once I figured that out (I welcomed static member functions with open arms, I just don't feel the need to code proxy thread classes! That's crap), I couldn't understand why my app kept crashing inside a thread using OpenGL calls. I thought it had to do with something I wasn't getting right when trying to recast a void*; however; some sleuthing made it clear that only OpenGL calls made the main process choke. All this eventually taught me a very valuable lesson...

READ THE INSTRUCTIONS FIRST!

The Apple documentation, conveniently titled "Multithreading and OpenGL," made it more than obvious that pitfalls run rampant across the OpenGL/Multithreading paradigm. Only a few sentences in gave me the clairvoyance I needed to see why my thread kept crashing.

I'll keep OpenGL calls within the main thread for now, but I look forward to working in Cocoa/Obj-C soon. At least there, OpenGL seems cared for delicately with plenty of out-of-the-box routines that are multithreading specific.