Thanks for the clarification, On Mon, Mar 2, 2015 at 11:29 AM, Gavin Lambert <gavinl@compacsort.com> wrote:
"One handler" does not necessarily mean "one application code handler". Many high-level async operations are actually composed internally of a sequence of lower-level operations. As such, it may require multiple internal handler calls before your user-level handler is actually called.
From your output, it appears that it your case it actually requires two handler calls to actually invoke your application handler. However you should not rely on this as it may change if the internals of Asio change or if some other condition in your execution environment changes.
Ok, so this explains the 6, and also explains the 1 for the run_one() test (i.e. my handler did not get invoked). I added run_one() a second time (with reset() in between) and my handler was invoked and count equals 1 as expected .
run_one() is intended to be called in a loop with other "idle" work -- but using run() is preferred whenever you can just post the extra work to the io_service anyway.
Ok, this is helpful.
Note that an async_wait is a single-shot thing anyway -- if you didn't call async_wait again in your handler then it would only catch the signal once, if that's what you're trying to do.
Yes. This was only a small test program to help me understand ASIO better. I was trying to use CTRL C was a mechanism to introduce a console event (also looked at posix::stream_descriptor) into the mix of socket (android) and serial port (arduino) events. thanks again.