Thank you very much Igor. <br><br>I acknowledge my ignorence regarding the thread safety issues involved, so I would like dig a little bit deeper here, if you do not mind. If there is a point in the docs that I should be looking and that I have not my apologies. I would appreciate it if you could point me there. <br>
<br>Most of the examples that I have come across for timers have as a precondition that the io_service::run function has been invoked yet; reseting the timer happens withing the timer handler in general. <br>I am wondering what are� the issues involved when calling deadline_timer::async_wait, deadline_timer::cancel for a timer that is associated with an io_service object when io_service::run has already started in a different thread? Or in other words following the point "<i> the io_service may be being
run in a background thread that is launched prior to the application's asynchronous
operations</i>"� in <a href="http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/reference/io_service.html">http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/reference/io_service.html</a>, how do I launch asynch operations using an io_service that has already being run?<br>
<br>This is relevant to what I really want to do which is:<br><br>1.Start io_service::run in one background thread<br>2.Start async timers on demand from the main thread that should be executed on the io_service::run thread. These timers will be associated with an event that will trigger a thread safe handler on a registerd observer(in this case the Counter class).<br>
3. Modify/cancel from the main thread timers that have outstanding async operations in the io_service::run thread. <br><br>In the particular example below, the member function onIncrement of the class Counter is not thread safe, but since the io_service::run is running on a one thread, only one handler will be invoked on the thread that runs io_service::run, so implicitly there is a serialization of access, correct? <br>
<br>My question is what is the best practice, in order to achieve 2 and 3 above? Suprisingly, after building my toy case with your help, the effect is what I expected, but I admit that your comment made me realize that I still need to dig further in order to understand all the issues involved. <br>
<br>I would be grateful for any comment or suggestion. <br><br>Thanks a lot. <br><br>Kimon<br><br><div class="gmail_quote">On Sat, Apr 25, 2009 at 8:38 PM, Igor R <span dir="ltr"><<a href="mailto:boost.lists@gmail.com">boost.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">> ��� ��� m_timer.async_wait(boost::bind(&IntervalEvent::handler, this));<br>
<br>
</div>should be: m_timer.async_wait(boost::bind(&IntervalEvent::handler, this, _1));<br>
or:<br>
m_timer.async_wait(boost::bind(&IntervalEvent::handler, this,<br>
boost::asio::placeholders::error));<br>
<div class="im"><br>
<br>
> ��� void handler(boost::system::error_code& error)<br>
</div>should be: void handler(cosnt boost::system::error_code& error)<br>
<div class="im"><br>
<br>
> Further to that, I am wondering, in principle should I cancel the deadline_timer on the destructor of the IntervalEvent class? Does the io_service class know when any of the deadline_timers that is being registered goes out of scope?<br>
<br>
</div>On destruction, the timer cancels itself anyway.<br>
<br>
By the way, you access the timers both from main() and from another<br>
thread - which is illegal, since the asio objects are not thread-safe<br>
(except for io_service).<br>
_______________________________________________<br>
Boost-users mailing list<br>
<a href="mailto:Boost-users@lists.boost.org">Boost-users@lists.boost.org</a><br>
<a href="http://lists.boost.org/mailman/listinfo.cgi/boost-users" target="_blank">http://lists.boost.org/mailman/listinfo.cgi/boost-users</a></blockquote></div><br>