22 января 2012, 06:26 от Brian Akins <brian@akins.org>:

> Won't embedded perl block in this case? I'm not as familiar with it. If it
> does, this seems like a sub-optimal solution. FastCGI would not block on the
> nginx side. It's pretty trivial to manage fastcgi processes.

It will block, but not indefinitely, only for as long as I want it to block.
That's why I used alarm to give open() 5 seconds to succeed - in case
it fails to open the FIFO within 5 seconds, it gets interrupted
(through SIGALRM) and since it fails the "or return 444" part
returns control to nginx to close the client's connection.

However, if the open() call succeeds within 5 seconds, the alarm
gets turned off (alarm 0) and then the FIFO is read from.

> It doesn't have to be fastcgi, it could be a min-http server uwsgi or whatever
> or is there some restriction that nginx must talk directly to the fifo?

Exactly, there are strict MAC (Mandatory Access Control) restrictions
in place. Even if there weren't, I'd still prefer the direct approach, it's
much simpler and cleaner, IMHO. Why would you want to use another
wrapper process and yet another process to supervise the wrapper
process and yet another process to read the FIFO and at least
another pair of sockets when you don't have to?

Max
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx