but I've also seen threaded programs which seem to run fine, blow up for no reason every 100th run

So have I, I wrote many of them.

But I've also seen the mess (and created more than a few) when trying to code naturally monolithic algorithms to fit in with a global-state driven, event/callback system. Of the two, I find that latter is much harder to debug. With a threaded mechanism, you can code the processing algorithm as a stand-alone, single threaded piece of code and get that right--then just throw it in a thread. If the algoritm fails, you have a problem in your threading/locking/synchro code to fix. You know where the problem lies.

With the state machine approach, you cannot test the monolithic part of the algorithm in isolation of the event driven part. Hence, your never quite sure in which part of the code the problem lies.

With threads, the usual problem is incorrectly protected access to shared variables or incorrectly done semaphoring. I avoid both possibilities by only sharing data through a tried (and by me, trusted) mechanism of Thread::Queue. I've yet to see it fail (since 5.8.4).

The two biggest problems with iThreads (IMO) are:

1. The synchronisation, locking and semaphoring APIs are simple wrappers around the broken pthreads APIs. The cond_* functions are too low level, too complicated and messy for general use. IMO they are broken at the design level and should be replaced.
2. The absence of thread prioritisation; suspend; resume; & kill function at the API level makes many things considerably more complicated than they should. It forces the user to hand implement stuff that should be a fundemental and integral part of any threading api.

That lack, in the pthreads API which iThreads are based around, makes iThreads less useful than they could be, but that does not mean that they aren't useful at all. Used within their limitations, they can greatly simplify some types of processing.

Event/callback apis are also useful for certain types of algorithm, especially those involving external interupts like UIs; but trying to force fit all your code to function in that manner is just painful.

Most effective is a combination of the two. Event driven to process asynchronous events; Normal procedural or OO coding for end-to-end stuff; and threads to allow the two to happily co-exist within the same process.

iThreads achieves this for the most part. The co-existance would be just that bit easier if there where ways of prioritising/suspending/resuming/terminating processing threads from the event driven code.