Day 9 - nginx master and servant (aka workers)

Today, I tried to figure out how nginx scripts work. So, I finally got to installing an IDE. I could have looked for the best IDE for C programming but I did not feel like spending too much time reading reviews. So, I went for what I know: Eclipse. This has nothing to do with nginx but I must say I'm not happy at the community attitude (for once). On one side you have gcj which seems to have difficulties getting their VM to work, on the other side you have the Eclipse team who claims "to test only for java/sun/Oracle -whatever their name is- VM), on yet another side you have the packaging team who packages the gcj and at the end of the day you have the poor user who gets something that doesn't work and must break his installation by adding the VM through the java/sun/Oracle RPM and tar xvzf eclipse. That was not my point but I couldn't resist making it.

So, wanting to see nginx scripts in action, I started my favorite IDE, set a breakpoint in the script compilation code (ngx_http_script.c for those of you who care) and started nginx with the 'out-of-the-box' configuration. That's when I realized what the "process-model" of nginx is. It's actually pretty standard: one master process that reads the configuration file and spawns "worker" processes that will do the job. When you send the appropriate signal to the master/parent process (which is what nginx -s reload ends up doing), then your master will just load the new configuration, stop the existing workers and spawn new ones (which now have the new configuration loaded). Simple, nice, efficient.

As I said, I was expecting to see scripts in action. More specifically, I was convinced the logging mechanism was using them (to handle the log_format directive) but I was obviously mistaken because I ran only once into my breakpoint and that was to compile "$proxy_host" for the http_proxy module. Therefore I looked at the logging mechanism but discovered that it uses its own mechanisms for parsing and managing log_format. I was a bit disappointed and I really wonder why it is so. Probably has to do with the fact that logging was implemented before the scripts and never refactored after scripts made it to the source tree. Of course, this is just guessing from me...