On Mon, Jun 20, 2011 at 11:23 AM, Luke Marsden <
luke-li...@hybrid-logic.co.uk> wrote:
> 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 so
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 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
