I need to access the thread lock in the _tkinter.c.

I have the following callgraph:
1) Python code
2) Tcl/Tk event loop (tkinter mainloop->)
3) Mouse callback to my own Tk extension widget
4) A lot of C++ stuff, which is also called directly
   from python
5) Python
6) Calling tk (which crashes due to the tk lock)

It is be possible to avoid this by creating a
tcl event with a python callback instead of calling
c++ from the tk extension widget. However, in a
painting program this is not ok for performance.
The real time capabilities of Python are pretty
bad and mouse movement becomes stopped for a few
milliseconds every now and then, leaving significant
discontinuities in the mouse tracking.

I have been able to have excellent behavior by
exposing the thread lock of _tkinter.c and release
the tk-lock when the call from the widget enters
the C++ side and lock it again when the C++ side
returns.

However, this is not possible with the standard
_tkinter.c, because the lock is a static member.
There are two possible solutions that would fix
my problems:

1) real-time python mode, that allows for turning
off GC and all other possible delays in the
interpreter. Then I could use the python for
managing tk events without mouse jumps.

2) exposing the thread lock with a simple api that
allows the use of LEAVE_TCL and ENTER_TCL outside
_tkinter.

The 2) is simpler. It consists of removing a keyword
"static" in _tkinter.c, while real-time python
is probably a 3.0 thing? Thus I would vote for a
fix in _tkinter.c for allowing me not to compile
my own python.

Logged In: YES 
user_id=21627

Just removing the static on the lock is not sufficient, if
_tkinter.so is a shared library. Instead, providing a
CObject in _tkinter would help.

Would you like to produce a patch for that?

No reply from OP, will close unless someone argues against it.

Why close ? It is still a valid feature request (with no patch yet).

Leaving open, then :)

Thanks!

@Guilherme I'm guessing that you're still interested in this, yes?

> @Guilherme I'm guessing that you're still interested in this, yes?

I don't see the point in closing an issue simple because no one
responded. I think the question to be asked is more towards "is it
solved?" than "are you interested on it?". If the issue is invalid
considering all the changes that happened since the initial message
then I'm in favor in closing it.