[Twisted-Python] GUI responsiveness

[Christopher Armstrong]

On 9/14/05, glyph at divmod.com <glyph at divmod.com> wrote:
> On Wed, 14 Sep 2005 13:35:35 +0200, Antoine Pitrou <solipsis at pitrou.net> wrote:
> >Suppose a network event is taking some time to process (e.g. the
> >protocol is complex and there are some calculations involved), then your
> >GUI will become unresponsive (a 100ms delay is not critical for most
> >Internet protocols, but it is for GUIs).
> 
> Not at all.  A user clicks on a button; if they don't see an update for 100ms, that is barely enough time for them to flick their mouse over to another button.  In fact, network latency is such that it is nearly impossible to provide faster than 100ms actual real response time even for highly performance-critical applications.

[etc, etc, all of glyph's points...]

Whether or not this argument is correct, it's unnecessary. There's a
much simpler way to argue this side of the threads-in-GUIs debate:

The way to write all Twisted applications, not just GUI ones, is that
you _DO NOT BLOCK_. Blocking for even a small amount of time in, for
example, a network server application, can eventually have disastrous
results for the usability of your network server application. If you
have CPU intensive functionality in your application, you need to
figure out a way to make it not block, by either (e.g.) breaking the
computation across reactor iterations, or by deferring those
individual operations to a thread, or process, or whatever. For other
sorts of operations, fortunately Twisted offers non-blocking
alternatives for many sorts of operations, like I/O. :-)

If you write your Twisted application in a way that isn't horrible,
your GUIs won't block. It's pretty simple.

-- 
  Twisted   |  Christopher Armstrong: International Man of Twistery
   Radix    |    -- http://radix.twistedmatrix.com
            |  Release Manager, Twisted Project
  \\\V///   |    -- http://twistedmatrix.com
   |o O|    |  
w----v----w-+