On 9/13/06, <b class="gmail_sendername">Andrew Francis</b> &lt;<a href="mailto:andrewfr_ice@yahoo.com">andrewfr_ice@yahoo.com</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
From: <a href="mailto:radix@twistedmatrix.com">radix@twistedmatrix.com</a><br>Radix&gt;You might want to check out<br>Radix&gt;<a href="http://www.stackless.com/wiki/TwistedOnStackless">http://www.stackless.com/wiki/TwistedOnStackless
</a><br><br>Radix, I have seen that webpage. However I did not see<br>how it would solve my fundamental problem, my<br>application blocking indefinitely when waiting for an<br>incoming connection.<br><br>To recap my problem, pretend one has the following
<br>situation:<br><br>[C(0) | C(1) | C(n) | S(0)]<br><br>C - client (making a connection)<br>S - server (accepting a connection)<br>| - running in parallel<br><br>In this scenario, the S will block Twisted and the<br>Stackless VM (Bob Ippolito pointed this out). Blocking
<br>cuts down on throughput. I don't see how Deferred help<br>here. However calls to TaskLoop that periodically call<br>a callback, which in turn, call stackless.schedule(),<br>giving waiting clients a chance to execute. Another
<br>advantage is that I can use TaskLoop to run a proper<br>timer.</blockquote><div><br>I have no idea how you got there. If you're using the usual connect and listen methods, connectTCP and listenTCP (and their siblings for UDP, SSL, etc), they will certainly not block.
<br><br></div></div>-- <br>Christopher Armstrong<br>International Man of Twistery<br><a href="http://radix.twistedmatrix.com/">http://radix.twistedmatrix.com/</a><br><a href="http://twistedmatrix.com/">http://twistedmatrix.com/
</a><br><a href="http://canonical.com/">http://canonical.com/</a><br>