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

2011-06-20 Thread Terry Jones
I posted to the mailing list a few years back with a Deferred class that can log what callbacks were called, what result they returned, etc. It would be very easy to add callback timing information to that. You'd just insert a callback into the chain of any deferred you wanted to monitor to have it

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

2011-06-20 Thread Luke Marsden
On Mon, 2011-06-20 at 11:09 -0400, Glyph Lefkowitz wrote: > On Jun 20, 2011, at 7:39 AM, Phil Mayers wrote: > > On 20/06/11 11:29, Orestis Markou wrote: > >> 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. > > > >

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

2011-06-20 Thread Glyph Lefkowitz
On Jun 20, 2011, at 7:39 AM, Phil Mayers wrote: > On 20/06/11 11:29, Orestis Markou wrote: > >> 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 ap

Re: [Twisted-Python] Handling application initialization synchronously

2011-06-20 Thread Itamar Turner-Trauring
On Mon, 2011-06-20 at 16:00 +0900, David wrote: > Hi, > > I was wondering what's the recommended way to initialize a "complex" > twisted application. Typically, let's say I have an application which > needs to create a couple of "heavy" objects, each of which may create > mysql db/tables:

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

2011-06-20 Thread Phil Mayers
On 20/06/11 11:29, Orestis Markou wrote: > 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 wo

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

2011-06-20 Thread Orestis Markou
>> 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 pro

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

2011-06-20 Thread Phil Mayers
On 06/20/2011 10:04 AM, Orestis Markou wrote: > Hello, > > I have a question about the "best practices" on making callbacks and > making sure you don't hog the reactor. > > So you pass a deferred to a client, who attaches a chain of callbacks Who is "you" and who is "client"? > that might probabl

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

2011-06-20 Thread Orestis Markou
Hello, I have a question about the "best practices" on making callbacks and making sure you don't hog the reactor. So you pass a deferred to a client, who attaches a chain of callbacks that might probably do some CPU intensive stuff. How should one guard for that? The obvious solution to me fo

Re: [Twisted-Python] Twisted training slides

2011-06-20 Thread Orestis Markou
I will try to make a proper tutorial out of them - please don't spread that file around, I'll remove it at some point. On 20 Jun 2011, at 00:05, AK wrote: > Thanks for the useful slides Orestis. Once you have finalized them, is > it ok to provide a link towards them from my blog or they are bound

[Twisted-Python] Handling application initialization synchronously

2011-06-20 Thread David
Hi, I was wondering what's the recommended way to initialize a "complex" twisted application. Typically, let's say I have an application which needs to create a couple of "heavy" objects, each of which may create mysql db/tables: class MyApplication(object): def __init__(self):