Python's garbage collector holds GIL during collection and doesn't
provide any method of interruption or concurrency with other Python
threads within a single Python VM. This can be a problem for realtime
applications. The worst-case performance of the garbage collector takes
linear time with respect to the number of Python objects that could
potentially be involved in a garbage cycle. I've attached timings taken
on a Core 2 Quad 2.4 GHz (WinXP Pro, 3GB RAM), with ever-increasing
numbers of objects. The gc at worst takes upwards of 3 seconds before
the process runs out of memory.

If gc periodically released the GIL it would allow it to be put in a
separate thread, but as it stands it blocks the Python VM for periods of
time that are too long for realtime interactive applications.
Alternatively a gc that is incremental by default would eliminate the
need for a second thread.