I&#39;ll try and put all my comments together with the feedback from everyone. Then I can pass it over to the defer documentation thread to see if they are interested in any part of it.<br><br>John<br><br><div class="gmail_quote">
On Thu, Aug 6, 2009 at 8:02 AM, John Aherne <span dir="ltr">&lt;<a href="mailto:johnaherne@rocs.co.uk">johnaherne@rocs.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">On Thu, Aug 6, 2009 at 1:12 AM, Jarrod Roberson <span dir="ltr">&lt;<a href="mailto:jarrod@vertigrated.com" target="_blank">jarrod@vertigrated.com</a>&gt;</span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
<div><br><br><div class="gmail_quote">On Wed, Aug 5, 2009 at 6:04 PM, John Aherne <span dir="ltr">&lt;<a href="mailto:johnaherne@rocs.co.uk" target="_blank">johnaherne@rocs.co.uk</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<div><div></div><div><br></div></div><div><br></div><div>2. If you have blocking code - <i>please define blocking</i> :), then first think about  putting it into deferToThread with appropriate callbacks and return the deferred. As suggested by Jarrod in his response.</div>


<br>
<br></blockquote></div><br></div>blocking code is code that will block or may potentially block the continued execution of the main reactor thread.<br>think for the most part long running processes or operations that may be long running.<br>


doing file or network i/o, calculating cpu intensive work, operations that may timeout like doing a remote call to another process or host machine, database operations are usually a culprit, that may be flooded with work or crashed, the examples go on but are mainly about i/o and cpu intensive operations.<br>


when these things happen on the reactor / main thread they block the server from doing anything else, it can&#39;t accept new connections, it can&#39;t do anything else until this blocking activity has completed and returned control to the reactor thread.<br>


<br>you can handle this without deferToThread by breaking the blocking code up into smaller pieces sometimes. need to transfer a large file to a socket, instead of trying to send it all at once send 10KB at a time and yield back to the reactor and reschedule the next 10KB until finished, this will work, it might not be the fastest way and still may block for an unacceptable amount of time on just 10KB, depending on how heavily taxed the i/o system is at the moment. Usually deferToThread is just easier to implement. <br>


<br></div></div>
Jarrod,</blockquote><div><br></div><div>Thanks. I&#39;ve incorporated some of what you said into a reply to my own mail. A point I should have added to my other ones first time round.</div><div><br></div><font color="#888888"><div>
John Aherne</div></font><div class="im">
<div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com" target="_blank">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>
<br></blockquote></div></div><br>
</blockquote></div><br>