Re: [Cppcms-users] multithread safety in async application
Brought to you by:
artyom-beilis
Menu
▾
▴
Re: [Cppcms-users] multithread safety in async application
|
From: Artyom B. <art...@ya...> - 2013-04-01 20:12:04
|
>________________________________ > From: Markus Raab <us...@ma...> >To: cpp...@li... >Sent: Monday, April 1, 2013 4:14 PM >Subject: [Cppcms-users] multithread safety in async application > >Hi Artyom! > >> Once you called async_flush_output you must wait for completion >> handler to be executed before you send more data. > >Do you mean by "send more data" streaming to response().out() or do you mean >calling async_flush_output again? > You can not call async_flush_output(), but you can write to response().out() the data would be buffered >Is following sequence correct or did I misunderstood something? > >publish thread 1 |publish thread 2 |async cppcms thread >mutex.lock() | | >response().out()<< | | >response().out()<< | | >async_flush_output()| | > | | > | |in on_complete() > | |mutex.unlock() > |mutex.lock() | > |response().out()<< | > |response().out()<< | > |async_flush_output()| > | | > | |in on_peer_reset() > | |mutex.unlock() >stop sending |stop sending | > >Is there a better sequence (that the threads can work more in parallel)? > >So I need to have a mutex between: >- before calling response().out() >and: >- on_complete() or on_peer_reset(). > No, you misunderstood the stuff. You can't access cppcms::http::context (and all its related objects like response) from the threads other than event loop thread. The lock would not help and for example some events (like on_peer_reset) my be triggered by timers you have no control over. What you need to do is to prepare a chunk and than pass it to the asynchronous application thread (even loop) via post() callback. What you propose is not safe. >Do I have a guarantee that either on_peer_reset() (callback of >cppcms::http::context::async_flush_output) or on_complete() (callback of >cppcms::http::context::async_on_peer_reset) is called in any case? > Yes, also on_complete is always called with success or error. on_peer_reset woks independently of sending sequence. on_peer_reset is also not called on normal completion. >> For example "state" sse service does exactly the same it sends >> only latest data and if some was missed between async_flush_output >> and completion handler it would not be sent, but rather latest >> data should be. > >Thank you for the examples, they are really great! > > >> About buffering, >> >> when you work with async app. the write to response().out() >> just collects the data to the buffer, the I/O is performed >> uput async_flush_output request and than you can continue >> once you receive the notification. > >Ok, good to know. See questions aboved about when exactly I am allowed to >continue. > >> So in general what you described is reasonable approach. > >Thanks, >Markus Raab > > >------------------------------------------------------------------------------ >Own the Future-Intel® Level Up Game Demo Contest 2013 >Rise to greatness in Intel's independent game demo contest. >Compete for recognition, cash, and the chance to get your game >on Steam. $5K grand prize plus 10 genre and skill prizes. >Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >_______________________________________________ >Cppcms-users mailing list >Cpp...@li... >https://lists.sourceforge.net/lists/listinfo/cppcms-users > > > Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/ |
