Logged In: YES 
user_id=764593

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?

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.

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.

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.

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)
"""

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)

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.