Main / Edit / History / / Users Area

Internals of CppCMS 1.x.x

The CppCMS framework consists of following parts:

Long Living Classes

Central service --- the major class that holds the main application loop and manages all resources.

All global resources are accessed via this service.

It also hold the main event driven execution loop based on boost::asio::io_service.
applications_pool --- it the class that holds a pool of user created applications and dispatches them according to requested url. It is the major connector between URL and application.

Each time the page is requested an application fetched from it and then returned back for recycling.
thread_pool --- is the thread pool for long running and time consuming jobs that can't be executed withing asynchronous event loop.

Generally, when new request arrives it is executed by application in the thread_pool.
locale::pool --- is the gateway to i18n and l10n world. It holds the set of std::locale for each supported locale required by developer. It also adds custom facets like gettext in order to extend localization capabilities behind the strict set of facets provided by standard C++.
The configuration of all CppCMS components is done via single JSON object that is loaded by service and accessible via json::object const &settings() member function of service class.

Connection Related Classes

When the main loop is started all incoming connections are accepted and processed by impl::cgi::connection class.

This is an abstract class that various protocol connectors implement it. Currently CppCMS supports following protocols:

HTTP --- very simple and limited implementation of HTTP protocol that is used for debug purposes or for running CppCMS behind http-proxy.
FastCGI --- connector that implements standard FastCGI web server API and allows running CppCMS application behind any web server.
SCGI --- connector that implements standard simple and very useful SCGI protocol that is simpler equivalent of complex FastCGI.

So, each time new connection is accepted it is read completely, including parsing headers and all POST data.

When the connection becomes ready it is assigned to user visible http::context object that provides an interface for user to lower level CGI like protocol.

When the http::context is ready, appropriate application is fetched from applications_pool and http::context object is assigned to it.

When application finishes response, it releases http::context object that sends all the pending data to output and releases cgi::impl::connection for further reuse --- keep-alive requests.

Then application is recycled to applications_pool for reuse.

Other classes are used together with http::context

http::request --- it holds all POST data and request information.
http::response --- it used as gateway for writing back all data.
locale::environment --- access to all localization facilities for given request.

Their lifetime is bounded to lifetime of http::context object.

Various Objects Lifetime

All dynamically created and destroyed objects are reference-counted. Their lifetime is tightly bounded to their users.

application --- it is probably most complicated class in terms of its lifetime.

When normal--synchronous application is fetched from the pool it receives a newly http::context and submitted to execution to the thread pool. When it completes the job, its reference counter goes to 0, and thus it is returned back to the pool releasing an http::context it owns.

However, any application may submit pending asynchronous jobs to the main even loop and thus extend its lifetime when the main loop becomes its owner --- they exist all the time there is the pending job to do and they are recycled at the end.

Another type of applications are long-running applications that are responsible providing Comet services.

These applications are unique in the system and each time new http::context is created it assigned to specific long running application, thus it can hold many contexts simultaneously and respond on them any time it needs.

Such application is generally owned by main event loop and it owns numerous connections.

When all handlers to such application are destroyed, its reference counter goes to 0 and this application is destroyed.
http::context is owned by application. When application has no more jobs to to it releases the http::context that releases impl::cgi::connection it owns.

This class is mostly proxy class between implementation specific connection and high level user API.
impl::cgi::connection derivatives are owned by the main even loop, until they are assigned to http::context.

When http::context completes response to client it checks if the connection can be kept-alive and if so, returns it to the main loop for the next request.