PROVIDED that I'm not tempted to use Tk functions in my working thread is it GUARANTEED that my code is safe?

Safe from what? I'll assume you mean: safe from problems arising as a result of using Tk in a threaded program.

Think of it this way. Every program that uses Tk is a threaded application. It may only have one thread, but it is still threaded.

Indeed -- certainly in Windows, and arguably in other OSs too, though I am very vague of their internals -- the fundamental unit of processing is the thread. It is threads that are scheduled by the scheduler, not processes.

So, if you take a single-threaded Tk app and start another thread that does nothing but sleep, will that bring the house down? I think you;d have to agree, probably not.

So what if instead of just sleeping, that thread loops around? Still probably safe. So what if it does lots of things: reads and write from disk; communicates via sockets; allocates big chunks of ram; and does billions of calculations; will that cause Tk to fall over? Again, my given understanding of iThreads is that because no memory is shared between threads unless you explicitly request for it to be so, there should be no interactions between threads that do not explicitly communicate.

Temper that "no interactions" with the knowledge that some things are process global. Eg. the screen, keyboard etc. But iThreads design is such that it will do its best to keep your threads separate except where you explicitly choose for them to interact.

Of course, if the threads were entirely separate, they might just as well be separate processes. Well almost. So to be really useful, it usually means that they need to communicate some way. And Thread::Queue is, to the very best of my knowledge, a safe way for threads to communicate.

Would I use tk and threads to control a nuclear power station, airliner or baby monitor. No. But for most non-life-critical applications, I'd be perfectly happy to.

But, guaranteed? No.