Regarding task_completion_event on the heap - the deliberate lack of a "reset" method left me stymied for a bit. Hadn't occurred to me to just re-initialize and let the assignment operator destroy the old one before copying a new one on top.
Regarding the call to cancel_current_task(), this page is pretty clear:
I'm not worried about DoWork() overlapping, but I did think about it. I deliberately put DoWork() and Start() in the order I chose; it's a lazy-man's way of trying to keep the periodicity of events as even as possible without going to the pain of recomputing a new delay each time. (There is at least one comprehensive discussion of this issue elsewhere in this forum.) In my case, the actual task period is on the order of 60-300 seconds, and the elapsed time of DoWork() is under 100msec. Given the scale (number of simultaneous tasks being performed) and durability (runs for weeks or months) I'm looking at, I know I can't actually be lazy; if I want to run a job every 60 seconds for months on end, I'm really going to have to recompute the delay each time (or set an absolute time for the deadline_timer, which is what I'll actually do).
Now that I've gone through this exercise and have all of this stuff tamped into my brain, I understand your final point (don't screw with tasks at all; just use the asio::deadline_timer::async_wait method to cause my DoWork() to be run). There's a small complication due to the cancellation race; if I cancel the timer and get back the answer "Sorry, the timer's already tripped and the work function has been invoked someplace", I can't immediately destroy whatever DoWork() is working on. I think I know how to finesse that.
Some of this was exercise; some of this was an attempt to build a generalizable mechanism I can use elsewhere in the code, later on in development. I appreciate your insights.
Jason
Regarding the call to cancel_current_task(), this page is pretty clear:
It is important to call cancel_current_task when you respond to cancellation because it transitions the task to the canceled state. If you return early instead of calling cancel_current_task, the operation transitions to the completed state and any value-based continuations are run.I was trying to code a bit more generally rather than just address the immediate need; if more continuations were chained on, for example, then the doc indicates that I have to propagate cancellation down the chain.
I'm not worried about DoWork() overlapping, but I did think about it. I deliberately put DoWork() and Start() in the order I chose; it's a lazy-man's way of trying to keep the periodicity of events as even as possible without going to the pain of recomputing a new delay each time. (There is at least one comprehensive discussion of this issue elsewhere in this forum.) In my case, the actual task period is on the order of 60-300 seconds, and the elapsed time of DoWork() is under 100msec. Given the scale (number of simultaneous tasks being performed) and durability (runs for weeks or months) I'm looking at, I know I can't actually be lazy; if I want to run a job every 60 seconds for months on end, I'm really going to have to recompute the delay each time (or set an absolute time for the deadline_timer, which is what I'll actually do).
Now that I've gone through this exercise and have all of this stuff tamped into my brain, I understand your final point (don't screw with tasks at all; just use the asio::deadline_timer::async_wait method to cause my DoWork() to be run). There's a small complication due to the cancellation race; if I cancel the timer and get back the answer "Sorry, the timer's already tripped and the work function has been invoked someplace", I can't immediately destroy whatever DoWork() is working on. I think I know how to finesse that.
Some of this was exercise; some of this was an attempt to build a generalizable mechanism I can use elsewhere in the code, later on in development. I appreciate your insights.
Jason
