Hi Garrett.<br>I'd say the best thing would be to take inspiration from how WSGI allows disparate apps + middleware to interoperate without having to keep track of each other's internal logic. It is an elegant API where you have a request, response headers, a response I/O stream, and that's pretty much it. You might be able to translate that into Erlang receiver patterns (or whatever) to make it fit better with Erlang. When it was translated to Ruby as Rack (<a href="http://rack.github.com/">http://rack.github.com/</a>) I thought they did a good job of simplifying the interface even further. A lot of that went into WSGI 2 so be sure to read up on that one too. <br>
<br>Kumar<br><br><div class="gmail_quote">On Thu, Oct 11, 2012 at 1:59 PM, Jordan Bettis <span dir="ltr"><<a href="mailto:jordanb@hafd.org" target="_blank">jordanb@hafd.org</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 10/11/2012 01:25 PM, Carl Karsten wrote:<br>
> On Wed, Oct 10, 2012 at 11:14 PM, Jordan Bettis <<a href="mailto:jordanb@hafd.org">jordanb@hafd.org</a>> wrote:<br>
>> But if there's no mechanism for setting the request aside, the the<br>
>> worker thread has to sit around doing nothing while the search server<br>
>> does its thing. An asynchronous framework would let the worker set the<br>
>> request aside and process new requests while it's waiting for the<br>
>> response from the search server.<br>
><br>
> What is the difference between "sit around doing nothing" and "setting<br>
> the request aside"  ?<br>
><br>
> I am guessing there is a resource (memory, connections, stack?) issue,<br>
> but I don't really see how either model is going to be much different,<br>
> so I must be missing something.<br>
><br>
<br>
</div>The assumption is that the application is setup as fixed pool of<br>
workers. A worker waiting for a third party response is one that can't<br>
process any more requests. Since sites with this configuration typically<br>
have about as many workers as they have cores, the number of workers per<br>
server is going to be on the order of dozens, and tying one up<br>
represents a serious waste.<br>
<br>
Of course you can have a dynamic worker pool. That's the way apache<br>
works. Given that python has a fairly "big boned" runtime, there's a<br>
substantial cost there, as well as doing other things like making DB<br>
connections for the new workers. And anyway it still only partially<br>
solves the problem. You're still going to run out of memory or file<br>
descriptors or something eventually. Compare Apache's behavior in the<br>
face of a Slow DOS attack compared to that of an asynchronous server<br>
like nginx.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Chicago mailing list<br>
<a href="mailto:Chicago@python.org">Chicago@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
</div></div></blockquote></div><br>