Message48642
Logged In: YES
user_id=488897
> (1) Why was the behavior different before?
Actually, the behavior is not much different from before;
this patch together with patch #1049855 essentially move the
event loop from Tkinter to Python core, so that it is
available to other extension modules also. But effectively
the program goes through the same steps as before.
If you want to know why the design of Tkinter's event loop
is the way it is: I am not quite sure, but it may just be a
quick solution to get Tkinter working (and it does work fine
as long as you're interested in Tkinter only). Since Tcl/Tk
already has an event loop, it is easy to run that event loop
and let it check for keyboard input (via
Tcl_CreateFileHandler in EventHook in _tkinter.c). Writing
such a loop for Python is not extremely difficult but also
not straightforward (see my woes with patch #1049855).
> Is 10 times per second not responsive enough?
With the current Python, the loop sleeps every 20 ms before
checking for keyboard input and handling Tcl/Tk events. With
the patch, Tcl/Tk events are handled every 100 ms; keyboard
input is handled much faster (depending on how quickly
"select" on Unix or "WaitForSingleObject" on Windows
respond to keyboard input). Of course, these delays can be
set to some other value in the code.
> Does a busy-wait of 10 times per second cause too much
thrashing?
I am not sure if I understand this question correctly. The
"select" function on Unix and "WaitForSingleObject" function
on Windows do not do a busy-wait.
> (2) It seems like the problem isn't really about Tkinter so
> much as it is about event loops vs threading. The event
> loop is infinite, so nothing else *in that thread* will
happen
> after it. This isn't solvable with a single-threaded
python.
Sure it's solvable. Even the current implementation of
Tkinter can handle Tcl/Tk events as well as listen for
keyboard input. If you import Tkinter and create a Tk
widget, you can still issue Python commands and move the Tk
widget around, even though they are running in the same
thread. The problem with the current implementation is that
it works for Tkinter only, and secondly, that it doesn't
allow chaining of hook functions. Patch #1049855 solves this
by calling select on Unix (WaitForSingleObject on Windows)
to find out if keyboard input is available, and if not, to
handle Tk/Tcl events. No need for a separate thread for that.
> (On the other hand, single-threaded python should never
> have the mutex problem you mentioned.)
> (3) With multi-threaded python, is there any reason not to
> start the event loop in a fresh thread? (And let that new
> thread block waiting for events.) This would also reduce
> contention with other frameworks that want to treat the
> "main" thread differently.
Yes, this is possible on multi-threaded python. However, an
extension module (such as Tkinter) cannot rely on the
assumption that Python is multi-threaded. Personally, I am
interested in PyOS_InputHook for scientific visualization
software, which is likely to be used on all kinds of
outlandish systems. I don't know if I can expect a
multi-threaded Python to be available on all those systems.
Secondly, given that Python has the PyOS_InputHook
functionality, why not make sure it is implemented
correctly? Meaning that its behavior should not depend on
whether readline is installed or not, and that its usage in
Tkinter does not block other extension modules from using it.
I am not sure if I interpreted all of your questions
correctly. Please let me know if I didn't.
|
|
Date |
User |
Action |
Args |
2007-08-23 15:43:38 | admin | link | issue1252236 messages |
2007-08-23 15:43:38 | admin | create | |
|