[Python-Dev] PEP needed? Introducing Tcl objects (original) (raw)

Martin v. Loewis martin@v.loewis.de
16 Feb 2002 13:29:02 +0100

"Jeff Hobbs" <JeffH@ActiveState.com> writes:

> It certainly is, but it is also necessary to have.

Why? I suspect if you inverted the control behavior to run the Tcl event loop as it's designed and trigger signals with TclAsyncMark, you would have no problem. Alternatively, you could do TclCreateEventSource, of if threading is really necessary, build Tcl with threads and use TclThreadQueueEvent.

Let me first state what I think what problem this Sleep call solves: it allows a thread switch to occur, by blocking the thread so that the OS knows that it should schedule a different thread. Otherwise, this thread would hold the tcl lock essentially forever, since releasing the tcl lock would be immediately followed by regaining it. Some thread implementation won't allow, in this case, other threads blocked for the tcl lock to run.

In the light of this rationale, can you please explain what Tcl_AsyncMark is and how it would avoid the problem, or what effect calling Tcl_CreateEventSource would have, or how Tcl_ThreadQueueEvent would help?

It has all the APIs to approach this from several different angles without have to toss a gratuitous Sleep in there that does nothing more than have people scratch their head and wonder why Tkinter appears so slow.

It does more than that: it avoids people thinking that their threads have blocked indefinitely, for no good reason.

BTW, I know you were tying into Tk before Tk was properly thread-safe, but those issues have been addressed (although it is highly recommended to stick to using Tk in one thread as things like X aren't guaranteed to be thread-safe).

Let's assume thread-safety of X is not a problem (as it isn't in most current installations). Are you then saying that Tk is thread-safe? What is the minimum Tk version that makes this guarantee? Where is this documented?

I'm all in favour of getting rid of the Tcl lock.

Regards, Martin