[Python-Dev] PEP needed? Introducing Tcl objects

[Martin v. Loewis]

"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
> Tcl_AsyncMark, you would have no problem.  Alternatively, you
> could do Tcl_CreateEventSource, of if threading is really
> necessary, build Tcl with threads and use Tcl_ThreadQueueEvent.

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