[Twisted-Python] GUI responsiveness

Stefano Masini stefano at pragma2000.com
Thu Sep 15 11:38:09 EDT 2005

On 9/15/05, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > 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.
> Provided it is a network server application, that is.
> If you are writing an asynchronous message-passing-based P2P app, then a
> 100ms or even 1s latency when sending/receiving packets isn't horrible
> at all.
> But it becomes horrible when the GUI is subject to the same 100ms
> delay ;)

I don't see your point Antoine.
Chris was pointing out that in an asynchronous model your event
handlers should not block. This means that if the task you're
performing - say round tripping a packet - is gonna take 100ms,
instead of waiting for it to complete - as you would in a synchronous
model - you're gonna break it up into, say, "initiation" and
"completion" phases. So your handler will only block for the duration
of the initiation phase, that will supposedly last a lot less that
100ms, maybe not more than 1ms, and return a deferred. Then the event
loop will go off and do other stuff. After 100 ms the deferred will
fire and some other part of your code will be called and perform the
completion phase.

So, if you do as you should, GUI responsiveness will not have anything
to deal with the actual round trip times of your protocol messages.

The problem with responsiveness will come up _only_ if for some reason
you have handlers that take a lot of time to run. For example if they
do complex computation or synchronous IO of large files, and stuff
like this.


More information about the Twisted-Python mailing list