[Tkinter-discuss] Revisiting the adage of GUI thread

[Nam Nguyen]

On Mon, Mar 26, 2018 at 12:40 PM, Bryan Oakley <bryan.oakley at gmail.com>
wrote:

> I think that part of the problem arises due to the fact that the tk
> library used by tkinter might not have been compiled with thread support.
> It's an explicit option required during the compile stage
> (--enable-threads). If you don't have a tk library compiled with thread
> support, then modifying tkinter objects from other threads can have typical
> thread-safety issues.
>
> Someone a while ago created a thread-safe version of tkinter called
> mttkinter. The README for that project  has this to say:
>
> Although tkinter is technically thread-safe (assuming Tk is built with
>> --enable-threads), practically speaking there are still problems when used
>> in multithreaded Python applications. The problems stem from the fact that
>> the _tkinter module attempts to gain control of the main thread via a
>> polling technique when processing calls from other threads. If it succeeds,
>> all is well. If it fails (i.e., after a timeout), the application receives
>> an exception with the message: RuntimeError: main thread is not in main
>> loop. There is no way to tell when this might happen, so calling Tk
>> routines from multiple threads seems to be problematic at best.
>
>
>
> Even with thread support, there appears to be bad interactions between the
> global interpreter lock (GIL) of python, and the underlying tcl interpreter
> used by Tkinter. Donal Fellows is one of the maintainers of the tcl core,
> and he provided additional information in this stackoverflow answer:
> http://stackoverflow.com/a/38767665/7432
>
> In that post he wrote:
>
> Each Tcl interpreter object (i.e., the context that knows how to run a Tcl
>> procedure) can only be safely used from the OS thread that creates it. This
>> is because Tcl doesn't use a global interpreter lock like Python, and
>> instead makes extensive use of thread-specific data to reduce the number of
>> locks required internally. (Well-written Tcl code can take advantage of
>> this to scale up very large on suitable hardware.)
>>
>
>
> Because of this, you must make sure that you only ever run Tcl commands or
>> Tkinter operations from a single thread;
>
>
This is where my confusion comes from, actually ;). Python is single
threaded (from the OS point of view). When I create the TCL interpreter, it
is also created in the same thread that runs the Python interpreter. So
regardless of how many Python threads (threading module), they all should
belong to this same OS thread, should they not?
​

>
> I trust Donal on this subject.
>
>
> On Mon, Mar 26, 2018 at 2:12 PM, Nam Nguyen via Tkinter-discuss <
> tkinter-discuss at python.org> wrote:
>
>> Hi,
>>
>> The adage often goes something like this:
>>
>> Do all GUI actions in a GUI thread (usually main thread), do I/O in
>> different threads.
>>
>> While it is a good wisdom to apply blanketly, I'm curious about bad
>> outcome from not following that advice. Other than the obvious blocking
>> nature of the event loop, which is why we need threads to work with it, is
>> there any other downside from directly creating, modifying, or destroying
>> Tk objects (such as widgets, variables) in non-GUI threads?
>>
>> Thanks!
>> Nam
>>
>> _______________________________________________
>> Tkinter-discuss mailing list
>> Tkinter-discuss at python.org
>> https://mail.python.org/mailman/listinfo/tkinter-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20180326/56b754a7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/tkinter-discuss/attachments/20180326/56b754a7/attachment-0001.bin>