And <a href="http://code.google.com/p/v8cgi/">http://code.google.com/p/v8cgi/</a><br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 9:37 AM, 张立冰 <span dir="ltr">&lt;<a href="mailto:zhang.libing@gmail.com">zhang.libing@gmail.com</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;">have a look at this project.<br><br><a href="http://github.com/rtyler/fastjs" target="_blank">http://github.com/rtyler/fastjs</a><div>

<div></div><div class="h5"><br><br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 4:10 AM, gerryw <span dir="ltr">&lt;<a href="mailto:nginx-forum@nginx.us" target="_blank">nginx-forum@nginx.us</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;">Hi,<br>
<br>
I considered FastCGI, but I&#39;m interested in a self contained solution. There would be very little difference in the code between both approaches and I didn&#39;t see the point in pushing it out to FastCGI. After looking at the FastCGI module, it&#39;s looks like the code I outlined will work. The main issue seems to be returning control to nginx as soon as possible. Whether the threads are running from nginx or a separate FastCGI process should make little difference from a system/performance perspective. The self contained solution would be much easier to configure/run. Does anyone see any issues with the module based approach?<br>



<br>
Thanks,<br>
-G<br>
<br>
Posted at Nginx Forum: <a href="http://forum.nginx.org/read.php?2,21573,21600#msg-21600" target="_blank">http://forum.nginx.org/read.php?2,21573,21600#msg-21600</a><br>
<br>
<br>
</blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <br>The time you enjoy wasting is not wasted time!<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>The time you enjoy wasting is not wasted time!<br>