[Twisted-Python] Question about "starving" the reactor

Orestis Markou orestis at orestis.gr
Mon Jun 20 06:29:13 EDT 2011


>> reactor.callLater(0, d.callback, arg)
> 
> That can help in some cases. Specifically if you're receiving datagrams, 
> you might want to service the read() loop as much as possible before 
> packets start to get dropped. But if d.callback is going to do a lot of 
> work, it doesn't solve the problem - just delays it.
> 
> callbacks/errbacks should not do a lot of work.
> 
>> 
>> insted of
>> 
>> d.callback(arg)
>> 
>> 
>> What about the client part? What would be the best way to have a
> 
> I don't really understand what you mean by client and server part. A 
> deferred is just a deferred. They don't even have to be used in a 
> network context.

By "server" I mean my application's API, by "client" I mean someone else that will go and attach callbacks to deferreds I will return.
I guess the question is, what is the best way to guard my application against callbacks that are doing a lot of work. But probably I'm confused by conflating the neglecting read() loop with starving the reactor.

It might be there's no way to do guarantee something like that, so it might be just that everyone should be careful about this.


More information about the Twisted-Python mailing list