There were some serious problem with the thread-safety code.
The basic problem was that often the result was gotten out of
the Tcl interpreter object after releasing the Tcl lock.
Of course, another thread might have changed the return value
already, and this was indeed happening.  (Amazing what trying
it on a different thread implementation does!)

The solution is to grab the Python lock without releasing the
Tcl lock, so it's safe to create a string object or set the
exceptions from the Tcl interpreter.  Once that's done, the
Tcl lock is released.

Note that it's now legal to acquire the Python lock while the
the Tcl lock is held; but the reverse is not true: the Python
lock must be released before the Tcl lock is acquired.  This
in order to avoid deadlines.  Fortunately, there don't seem to
be any problems with this.