Message48644
Logged In: YES
user_id=488897
> Clarifying (1a) -- Why (pre-patch) were Windows and
> Unix intentionally set to act differently? Is there
something
> in the default runtimes or libraries which makes
> (expected?) performance very different on the platforms?
The difference is not Windows versus Unix, but
Unix-with-readline versus Unix-without-readline and
Windows-without-readline. I wasn't there when PyOS_InputHook
was first added to Python, but I doubt that the difference
in behavior was intentional. Essentially, I think that the
behavior of Tkinter (on Python-without-readline) is a design
flaw.
> Clarifying (1b) -- Is ten times per second enough? 0.1
> seconds is long enough that people can notice it. If the
> pre-patch version cycles 50 times/second, then going to
> only 10 times/second might make the interface seem
> sluggish. I'm not sure I'm qualified to make this
> judgement myself, but it is a concern.
Good point. The 10 times/second is the default used in
readline, and hence this is the frequency at which
PyOS_InputHook is called in Python-with-readline. I can
modify the patch to increase this to 50 times/second.
> Clarifying (1c) -- My (possibly wrong) understanding is
> that before this pair of patches, unix effectively did an
> active check for input, but the windows version waited for
> notification from the OS that keyboard input was available
> -- and after this, both would actively check N times/
> second. If both are just passively waiting, then I'm not
> sure what the 20ms/100ms timeout actually does.
That is correct. Pre-patch, both Unix and Windows sit in a
loop inside Tkinter's EventHook function that calls
Tcl_DoOneEvent and check for keyboard input, and then sleep
for 20 ms. The check for keyboard input is done via a call
to _kbhit (on Windows) or select (on Unix, hiding inside
Tcl/Tk's Tcl_DoOneEvent function). Post-patch, this loop is
located inside the my_fgets function. It works essentially
the same, except that I'm using WaitForSingleObject (on
Windows) / select (on Unix) for the timeout.
> If python is running as a batch process, then forcing it
> back into the "is there input" section several times a
> second (even though there is never any keyboard input)
> will cause the program to take more clocktime.
Also a good point. I will modify the patch such that it will
skip to fgets immediately if PyOS_InputHook==NULL. In a
batch process, there is no reason to load a GUI extension
module such as Tkinter, so PyOS_InputHook should be NULL.
> Clarifying (2) -- The pre-patch version can certainly take
> events (including keyboard events) during the event loop.
> What you can't do is:
> """
> (define/run a bunch of stuff)
> ...
> start the event loop
> ...
> (define/run a bunch more stuff)
> """
Sure you can. I do it all the time. Try this, for example:
>>> from Tkinter import *
>>> Label(text="Label1").pack()
# ... Label1 appears
>>> print "more stuff I want to do"
more stuff I want to do
Here, Label1 appears and responds to events, even though I
did not run mainloop. Note that pre-patch, this does not
work on Cygwin; post-patch, it works on Cygwin too.
> You need to set up all the definitions and event handlers
> before the loop starts, or else do them as a result of
> events. Roughly, calling mainloop has to be the *last*
> thing you do in a given thread. Which leads to (3)
You don't need to call mainloop at all. This is quite useful
for scientific visualization:
>>> do_some_calculation()
>>> plot_the_result()
>>> if dont_like_the_plot: do_some_more_calculations()
>>> plot_the_new_result()
Here, you never need to start or stop the event loop. It
continues running as long as PyOS_InputHook is set
appropriately by the extension module that does the plotting.
> Clarifying (3) -- Why not just assume threads? The
> problem you are trying to solve can't exist without threads.
> Assuming threads won't make anything fail any harder
> than it does now. If you default to dummy-threads and
> ensure that the event-loop the *last* pseudo-thread, you'll
> even clear up some bugs in carelessly written single-
> threaded code.
Whether or not Tkinter should have been coded with threads
is a separate question. Tkinter is written for a single
thread, using an event loop to handle window events and
keyboard input. While it is possible to rewrite Tkinter to
use threads, that would constitute a separate patch (and
would probably not have a good chance of getting accepted,
since Tkinter already works well as a single thread). |
|
Date |
User |
Action |
Args |
2007-08-23 15:43:38 | admin | link | issue1252236 messages |
2007-08-23 15:43:38 | admin | create | |
|