Thanks, I understand what you mean. But I am still confuse about the multi-request for Fastcgipp.
When many request come to the Fastcgipp, if I use one process to handle it. It means I should use multi-thread to handle it(e.g boost::asio to support)?
Can you give me other multi-thread examples to handle it (except the website).
Thanks~
At 2012-03-03 01:00:47,address@hidden wrote:
>Send Fastcgipp-users mailing list submissions to
> address@hidden
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.nongnu.org/mailman/listinfo/fastcgipp-users
>or, via email, send a message with subject or body 'help' to
> address@hidden
>
>You can reach the person managing the list at
> address@hidden
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Fastcgipp-users digest..."
>
>
>Today's Topics:
>
> 1. Re: Question about Fastcgi++ mechanism (lxs567890)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 2 Mar 2012 14:45:12 +0800 (CST)
>From: lxs567890 <address@hidden>
>To: address@hidden
>Subject: Re: [Fastcgipp-users] Question about Fastcgi++ mechanism
>Message-ID: <address@hidden>
>Content-Type: text/plain; charset="gbk"
>
> Hi, now I'm making RESTFUL API for my system through Nginx+Fastcgi++.
>But I'm wondering how can I seperate the write and read request in the Fastcgi++ agent. If I use one process for Fastcgi++, when the read request arrived, it can't response to the other request.
>I want to know whether I can make the read or write operation on the poll loop. If the request has been done, I can call the response to return the result.
>
>Thanks!
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://lists.nongnu.org/archive/html/fastcgipp-users/attachments/20120302/475227c5/attachment.html>
>
>------------------------------
>
>_______________________________________________
>Fastcgipp-users mailing list
>address@hidden
>https://lists.nongnu.org/mailman/listinfo/fastcgipp-users
>
>
>End of Fastcgipp-users Digest, Vol 18, Issue 1
>**********************************************