[Twisted-Python] Two main loops

Jean-Paul Calderone exarkun at divmod.com
Mon Nov 12 12:13:44 EST 2007

On Mon, 12 Nov 2007 08:58:55 -0800, Jasper <jasper at peak.org> wrote:
>Maarten ter Huurne wrote:
>>On Sunday 11 November 2007, Jasper wrote:
>>>Jean-Paul Calderone wrote:
>>>>Practically speaking, you probably don't need to render more than about
>>>>3000 frames per second.  ;)
>>>That depends.  When I send moderately sized objects over Twisted, this
>>>approach causes my frame rate to stop while Twisted is busy, and worse
>>>makes my GUI non-interactive.  For a game, this is generally
>>Why would that happen?
>>Twisted never blocks; if it has to wait for something (such as a 
>>transmission buffer becoming ready to accept more data), it will register a 
>>callback and the reactor will continue (and call your rendering code).
>>                 Maarten
>Maybe I'm misunderstanding what's going on underneath, but Twisted sure 
>seems to block while I send one large chunk of data.

There are a lot of different pieces in any non-trivial program.  There are
also at least a couple different meanings for the word "block".

The network code at the very bottom of Twisted won't ever wait for a
network event to happen before continuing execution.  That's what Maarten
ter Huurne was pointing out.

Some parts of Twisted (for example, the serializers for PB) might spend a
long time using the CPU in order to provide the functionality they are
supposed to provide.

The main difference between these two cases is that in the former, you are
subject to arbitrary delays by other parties whereas in the latter case,
the delays are in response to actions your application has explicitly taken.

The latter case can be solved by asking functions to do less work at a time,
as has been suggested a couple times in this thread.  Since the former case
never happens in Twisted, there's no need to fix it. :)


More information about the Twisted-Python mailing list