In Tcl-land, we often discourage use of threads, for reasons documented elsewhere [explain]. Here's an example of how to think about design involving threads:
Briefly, Tcl applications need threads when they rely on long-running external resources, like database look-up or communications with physical devices [references]. Even in the latter case, though, there are a number of alternatives:
[Use of dqkit as a great convenience.]
rfoxmich (and SO and CL) say(s): "... timeouts belong inside the extension that interfaces with the hardware itself."
SG Sep 07 2006: I think that the advice to avoid threads is overstated. Understandable, but overstated. Tcl's thread implementation is actually quite nice and threads coexist rather well with event-driven programs in that inter-thread communication *is* an event.
The rule of thumb I've developed is if you have when you have mutliple (largely) orthogonal event sources *and* you would have to re-write code to enable event processing to occur in a timely fashion then you have a good candidate for threads.
Threads let you code at a higher level of granularity and let the OS be resposible for time sharing. It's much easier than trying to break your code down into smaller blocks that are strung together via the event loop if that's not the natural way of expressing it. And (IMO) thread::launch/thread::send is a much cleaner way of interacting than bgexec and pipes and whatnot.
I avoided Tcl's threads for a long time but since I started using it, I think it ought to be promoted more. Not for everything (and threads are often overused) but there are a class of problems that threads provide a clean solution for. A hardware controller is often one of those problems.