Event-driven handler

[Marcus Clyne]

>> [in Nginx]
>> - loop that checks every e.g. 0.001 secs to see if there are any responses
>>     
>
> this is going to fail spectacularly.
>
>   
This was my gut instinct (it sounds a horrible idea) and is something I 
wanted to avoid at all costs.
It was more of a desperation attempt to not put things in an external 
process.

> what is the content generator? are you writing it from scratch? if it
> connects to external sockets and doesn't use nginx's event loop or is
> blocking  - it should be an external process and you should use an
> upstream module. if you are writing from scratch (that is all of the
> socket code too) you are possibly not on the wrong path (unlikely)
>   
Yes, as my understanding of the internals of Nginx are increasing, I 
think I agree with you
on this one. I am writing the content generator from scratch.
> You should be talking via pipes/sockets to your content generator and
> getting callbacks on those via the event loop.    And if you're
> talking to another thread via pipes already you might as well save the
> trouble and move it into its own process and use the already written
> mature upstream modules. Just compiling a bunch of random code into
> Nginx is not going to make it fast.  You either design it from the
> ground up very carefully or use external processes.
>
>   
I think I've come round to the idea that you're right on this one.  I 
think what I'm doing
will be too messy to try to get it working inside Nginx, even though I'd 
prefer to do it that
way. I'm looking at both FastCGI and a customized format which I'd use 
with the upstream
module as possible solutions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090218/b541b936/attachment.html>