## 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 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. |
|
|
## 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 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.
|
|
|
|
