<br><br><div class="gmail_quote">On Mon, Jun 20, 2011 at 11:23 AM, Luke Marsden <span dir="ltr"><<a href="mailto:luke-lists@hybrid-logic.co.uk">luke-lists@hybrid-logic.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, 2011-06-20 at 11:09 -0400, Glyph Lefkowitz wrote:<br>
> On Jun 20, 2011, at 7:39 AM, Phil Mayers wrote:<br>
> > On 20/06/11 11:29, Orestis Markou wrote:<br>
</div><div class="im">> >> It might be there's no way to do guarantee something like that, so it<br>
> >> might be just that everyone should be careful about this.<br>
> ><br>
> > I don't think you can stop callers of a function doing silly things with<br>
> > the return value.<br>
><br>
> +1. The best way to deal with this is to make your APIs nice and<br>
> simple, and their implementation straightforward. If you try to do<br>
> weird tricks to make callbacks on your Deferreds cooperative, then you<br>
> might break an otherwise reasonable strategy on the part of the client<br>
> code to be well-behaved on their part.<br>
><br>
> For the code that is itself trying to be well-behaved, there are<br>
> things like twisted.internet.task.cooperate.<br>
<br>
</div>There might not be any way to stop consumers of your Deferreds executing<br>
blocking operations, but when trying to track down which pieces of code<br>
are the culprits, I found exarkun's BigTimesliceTimer very useful:<br>
<br>
<a href="http://twistedmatrix.com/trac/browser/sandbox/exarkun/btt.py" target="_blank">http://twistedmatrix.com/trac/browser/sandbox/exarkun/btt.py</a></blockquote><div><br></div><div>On that note, I made an updated version of the btt: <a href="http://pastebin.com/uBbSuDr6">http://pastebin.com/uBbSuDr6</a></div>
<div><br></div><div>I know i'm digging up ancient history here, but I thought it was relevant </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
It uses a reactor-independent timing mechanism (the setitimer sigcall on<br>
Linux, contact me if you want the FreeBSD version) to set an alarm which<br>
the reactor then has to "race" to unset, else the itimer handler gets<br>
pre-emptively executed. When the alarm runs, it prints a traceback of<br>
the current execution point in the "client" code. By setting the alarm<br>
frequency sufficiently low and by watching for sufficiently long you can<br>
"sample" the code which is running while the reactor is blocked. Code<br>
paths which show up frequently are therefore *more likely* to be the<br>
culprits.<br>
<br>
One day it would be nice to turn this into some kind of statistical tool<br>
for highlighting which code paths are the "hot-spots" in your code, so<br>
that you can optimise the "blockiest" bits first. Premature<br>
optimisation, etc.<br>
<br>
Hope this helps; it helped me :-)<br>
<font color="#888888"><br>
--<br>
Best Regards,<br>
Luke Marsden<br>
CTO, Hybrid Logic Ltd.<br>
<br>
Web: <a href="http://www.hybrid-cluster.com/" target="_blank">http://www.hybrid-cluster.com/</a><br>
Hybrid Web Cluster - cloud web hosting<br>
<br>
Phone: <a href="tel:%2B447791750420" value="+447791750420">+447791750420</a><br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</div></div></blockquote></div><br>