Re: [Cppcms-users] Synchronous app calls io_service.post() and blocks itself

[CN <cn...@fa...>]

Dear Artyom,

Many thanks for your swift and thorough clarification! It will take me
some time to digest your responses as I feel they contain so many
invaluable concepts.

> this is a synchronous app that it isn't correct (in most of cases)

Unfortunately "this" falls to this category. It refers to a descendant
of synchronous cppcms::application that is to be invoked by
cppcms::applications_factory.

> Now the case when you actually make the sync app to wait for the
> response...
> 
> technically you can implement this by for example waiting for a
> conditional variable.
> that would be changed in the event loop:
> 
> Caller
> ------------------
> 
> this->resp_is_ready=false
> 
> async_app->service().get_io_service().post(boost::bind(&my_class::my_method,this));
> 
> while(true){
>     booster::unique_lock guard(this->resp_is_ready_mutex)
>     this->resp_is_ready_cond.wait(guard)
>     if(this->resp_is_ready)
>       break;
> } 
> -------------
> Handler
> ---------------------
> 
> my_class:my_method()
> {
>    // do something with async app/withing the event loop
> 
>     booster::unique_lock guard(this->resp_is_ready_mutex);
>     this->resp_is_ready = true
>     this->resp_is_ready_cond.notify_one()
>   
> }

By the way, I started to investigate std::future and std::promise. I am
not quite sure, yet, if they can be incorporated into cppcms framework.
Then I feel the last approach you offered (see below) is the most
elegant way for me to go.

> If you need to do a fast query from the event loop for some data without
> running too many mutexes
> it is ok. However it is still somewhat borderline. I'd suggest to keep
> some data in some global object
> with very short and fast accesses protected by mutexes.

Such hand made "cache" seems to be unable to fit my case. I need to use
booster::aio::io_service as a synchronizer, like a mutex, to 
*sequentially* execute cppdb operations and manipulate in-memory data.

> But... if you want to put the thread on hold for a long time (for example
> to wait for some other event),
> it is very bad idea as you may run out of threads in the pool very fast.
> 
> If you want to postpone the response of the synchronous application you
> may do the following steps:
> 
> (a) detach the http::context (like in async app)
> (b) change the response().io_mode() to asynchronous
> (c) send the detached http::context to the async_app to handle it
> asynchronously vio post()...
> 
> So basically sync app tells I don't want to handle it and give it away to
> the async app.

I feel this (the last 3 steps) is the most elegant solution of all, and
easy to follow.

Best Regards,
CN

-- 
http://www.fastmail.fm - A fast, anti-spam email service.