== What Python threads are good for

Because of the sometimes much-maligned Global Interpreter Lock, pure
Python code itself can't run simultaneously on multiple CPUs. So what
should you use Python threads for?

The real use for Python threads is turning synchronous functions in
extension modules into asynchronous things that don't delay your main
program. Often these functions have no asynchronous equivalents (unlike
network IO), so it is either use threads or have your main program
delayed. This works for sufficiently compute-intensive functions as well
as functions, like _socket.gethostbyname_, that have to wait on outside
things.

Python threads are not a good way to do asynchronous network IO,
because it's inefficient overkill; use either _select()_ or _poll()_
from the
[[select module|http://www.python.org/doc/current/lib/module-select.html]]
instead (along with non-blocking sockets and so on). If you need a
canned solution for this, consider
[[Twisted|http://twistedmatrix.com/]],
or [[asyncore|http://docs.python.org/lib/module-asyncore.html]] and
[[asynchat|http://docs.python.org/lib/module-asynchat.html]] from the
standard library.

Note that threads are the only way to make _gethostbyname()_ and
_gethostbyaddr()_ asynchronous, because they don't necessarily just do
DNS lookups. Exactly what data sources they consult and how is highly
system dependent; you *really* need to just be calling the platform C
library routines. This cuts both ways; if you want just DNS lookups,
do just DNS lookups via something like [[dnspython|PythonDNSQueries]].

My thread-using Python programs wind up being built around completion
queues and thread pools; they hand off work to auxiliary threads and
then wait for things to finish. (Sometimes in conjunction with network
IO; see [[here|../programming/WaitingForIOAndThreads]] for how I mix
work completion notification and _select()_ et al.)

(Someday I will have a general 'thread pool' module that I'm happy
with. I probably need to write more thread-using programs first.)