Re: [Cppcms-users] 100% cpu usage

[Petr J. <ele...@ex...>]

> Until now... I said this is stub only until now. I could split them into
> sync and async operations and provide two different classes for them.
> This code is totaly under development and still in early pre-alpha ;)

Generally, an async app is designed to handle multiple connections, and
that's it. It's used when you need to push data to multiple clients at
the same time. ie. stock market price update.

> So this means, one thread for all async apps, but multiple workers for
> the thread pool?
> How is the async app connected to the thread pool? Why does it block it?
> That makes no sense to me :/
I'm going to summarize the differences between synchronous,
asynchronous, event loop, and thread pool here.

Synchronous operation = request in -> response out
Asynchronous operation = connection in -> non-blocking wait -> response
out when data is ready

The key is non-blocking wait. You can have thousands of connections in
non-blocking wait, all waiting for a single information/data to be
processed. When the data is ready, it's sent out at the same time to
all, or some clients.

Event loop is the central dispatch point of cppcms. When a connection
comes in, it goes to the event loop first. The even loop is really just
a loop. If you are blocking in the event loop, you are blocking the
whole application.

If the application is synchronous (using the application_factory class),
it is immediately dispatched from the event loop to the thread pool,
therefore it doesn't block. (thread_pool::post() is a non-blocking
operation, and it returns immediately)

If the application is asynchronous, it's using booster::intrusive_ptr
class. This application is running inside the event loop, and therefore
must NOT block.

Communication between the event loop and the thread pool is facilitated
using thread_pool::post() and service::post() methods.

They take a functor as an argument.

Petr