## Rule of Thumb |
|
All classes are not thread safe for access from multiple |
threads simultaneously unless it is stated explicitly otherwise. |
|
In general there are several thread safe classes |
in the CppCMS that their member functions |
can be accessed simultaneously from several threads: |
|
- `cppcms::service` |
- `cppcms::applications_pool` |
- `cppcms::thread_pool` |
- `cppcms::views::pool` |
- `booster::aio::io_service` |
|
In all other cases special measures should be |
taken in order to prevent accessing same class |
from multiple threads. |
|
## Threads in CppCMS |
|
There are several types of threads in CppCMS: |
|
- Event Loop - the main thread, the thread that runs |
the `cppcms::service::run()` threads. |
- Thread Pool - the special pool of threads that |
every synchronous requests are executed there |
- Some background threads auxiliary threads |
that are in general do not interest you. |
that are in general of no interest to you. |
|
|
## Cross Thread Interactions |
|
Once the CppCMS service started all synchronous |
applications are executed in the thread pool. |
|
If CppCMS synchronous application wants to perform |
some operation withing event loop, for example, |
interact with some asynchronous application by |
sending some data or by transferring its HTTP |
context to it, it should do it using |
`cppcms::service::post()` member function |
and an appropriate execution handler. |
|
This handler would be dispatched to the event loop |
queue and executed in its thread. |
|
If asynchronous application or any other object |
that runs in the event wants to execute some long |
running, blocking or heavy operation, it may do it |
by submitting an execution handler to the thread pool. |
|
Note, once the job is complete, the handler should notify |
its completion by posting some handler to the event |
loop, the same way as described above. |
|
Different applications should never access their |
internal states directly as it is not safe. |
|
|
|
