There have been lot of work in recent weeks in order to make deep internal changes in the framework. Now they include:
- Transparent support of 3 web server APIs: fastcgi, cgi and scgi.
- Support of new mod prefork that allows safer management of worker processes.
- Implementation of a cache that is shared between forked processes.
There are 3 application-server communication protocols are supported:
- The old and not so good CGI
- FastCGI -- the default and the recommended one
- SimpleCGI or scgi -- a simpler alternative to FastCGI.
Configuration of all protocols is transparent and defined in configuration parameters. Any other CGI like protocol can be easily supported.
Mod prefork and new caching module
New execution mode was implemented --- mod-prefork. How does it work? When process starts it forks a number of "worker" process that accept incoming requests and execute them. If one of the workers dies it is immediately replaced by a new freshly forked process. This way, even critical bugs in programs will not cause the shutdown of the service.
This mod also has a "life time" option for worker processes. Setting the life time to some limit would allow transparent and instant replacement of working processes by a fresh childes eliminating any possibilities of memory leaks.
The major problem for implementing prefork module was implementation of cache. However simple and elegant solution was found.
A segment of shared memory was created before the process are forked. The cache module code was based on original "thread shared" caching module that was written using STL with a little difference: all allocators where replaced be the new that allocated a memory from a pool placed in the shared segment using libmm.
Because all process are forked from the same parent, there is no typical shared memory problem -- inconsistent pointers.
Thus the effort to rewrite the caching system was as big as writing new allocators for STL.
And how is performance? Maybe only a few percents lower then with mod thread.