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
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.
> >
> >
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
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:
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
>> 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
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
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
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
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):
10 matches
Mail list logo