Is mod_php walking on its road?

[Thomas Seifert]

The doc-page tells for the module below:
"If a Perl module performs protracted operation, (for example DNS
lookups, database queries, etc), then the process that is running the
Perl script is completely tied up for the duration of script. Therefore
embedded Perl scripts should be extremely careful to limit themselves to
short, predictable operations."

So it blocks too.



thomas

Steve Chu schrieb:
> I mean, why mod_perl not blocked?
>
> On 10/24/07, Igor Sysoev <is at rambler-co.ru> wrote:
>   
>> On Wed, Oct 24, 2007 at 10:14:19AM +0800, Steve Chu wrote:
>>
>>     
>>> What about mod_perl?
>>>       
>> There is experimenatl ngx_http_perl_module:
>> http://wiki.codemongers.com/NginxEmbeddedPerlModule
>>
>>     
>>> On 10/23/07, Manlio Perillo <manlio_perillo at libero.it> wrote:
>>>       
>>>> Steve Chu ha scritto:
>>>>         
>>>>> Sorry,all
>>>>>     I made a mistake, nginx is using epoll, so blocked I/O will be a
>>>>> big problem.
>>>>>           
>>>> Not a "really big" problem, since nginx can use multiple worker processes.
>>>>
>>>> Of course mod_wsgi *should* not be used in the "main" http server, but
>>>> it should be used "standalone", as a replacement for a "builtin" server
>>>> and behind another nginx proxy if possible.
>>>>
>>>> With Python this is very effective, since all Python http servers are
>>>> written in pure Python and use a thread based model.
>>>>
>>>> With PHP the builtin server is written in C, and uses a prefork model
>>>> (if I'm right) so I don't know is a nginx mod_php is worth the effort.
>>>>
>>>>
>>>>
>>>> Regards  Manlio Perillo
>>>>
>>>>
>>>>         
>>> --
>>> Steve Chu
>>> http://stvchu.org
>>>
>>>       
>> --
>> Igor Sysoev
>> http://sysoev.ru/en/
>>
>>
>>     
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20071024/2ce0a734/attachment.html>