Re: [Boost-users] [asio] Async (or sync) in threads

Subject: Re: [Boost-users] [asio] Async (or sync) in threads
From: Anthony Foiani (tkil_at_[hidden])
Date: 2013-07-25 16:40:38

Michael Powell <mwpowellhtx_at_[hidden]> writes:

> On Thu, Jul 25, 2013 at 2:30 AM, Anthony Foiani <tkil_at_[hidden]> wrote:
> > Given that thread interruption is a bit dicey, you might consider
> > doing the timeout work in the thread / io_service itself.  That
> > way, the controller only needs to launch the thread, then join it.

> Not sure what you mean by dicey. If by dicey you mean that accept()
> blocks altogether, interrupt requests and all, then, yes, I'll agree
> dicey.

I only meant that boost thread interrupts are processed only at very
specific times; I don't recall offhand if an ASIO synchronous accept
would qualify.  There's a list of them here:

http://www.boost.org/doc/libs/1_54_0/doc/html/thread/thread_management.html#thread.thread_management.tutorial.interruption
(or: http://preview.tinyurl.com/p959dyz )

> Obviously, this won't work either, because if a client never connects
> (which is a possibility when testing), then that can't hang up the
> rest of the app.
>
> Can you be more specific? In the io_service itself?

The author of ASIO gave the basic pattern for implementing timeouts in
his blog, let me find the link...

  http://blog.think-async.com/2010/04/timeouts-by-analogy.html

The basic idea is that you start two asynchronous actions:

  1. async accept (calls handler when a connection comes in).

  2. timer (calls handler when timer expires).

Note that the timer (2) doesn't have to be for the whole duration of
the timeout; to use Chris's analogy, it's only how often you want to
check the "parking meter", not the actual time on the meter itself.

Now, in your accept handler, you cancel the timer (or at least reset
the "parking meter" counter, so that the timer sees that you've "fed
the meter".)

In your timer handler, you check the meter; if it has expired, you
cancel the accept operation.

(These two operations should probably be done against the same
io_service; if that io_service is being run by multiple threads, you
will have to make sure to deal with synchronization issues.  Easiest
is probably to run an acceptor and its timer in a single strand.)

I use exactly this pattern for read timeouts, and it works great.

> > Since you're catching exceptions *anyway*, don't bother with error
> > codes unless you're detecting specific values (as you do for eof
> > elsewhere).
>
> I am, I believe, checking for bytes, are bytes available, this sort
> of thing. Instead of receive blocking when there is no data, which
> is one plausible use case.

The use above is checking the error code return from synchronous
accept; that shouldn't indicate "bytes available", so much as
"something went very wrong with the acceptor".  That's why I was
suggesting that you just use exceptions.

Error codes from something like read_until can sometimes give you the
information you want, but that's pretty rare.  The typical ASIO style
is to set things up so your code is "told" when there is data
available, without needing to poll data sources.

> As soon as I schedule an async_accept, I get a segmentation fault.
>
> I don't know the inner workings of the io_service that well, but I
> suspect that may be because I have created the server outside the
> running thread.

Hm... so long as the execution context (in this case, the stack frame
in which you allocated the server) is still active, then you should be
fine.  But if you exit that frame after creating it, then yes, that
object has been destructed, and you're asking the io_service to run on
garbage memory.

> Something you mentioned earlier though, which is starting to click
> with me: io_service might be the thing I want to run and/or have time
> out, and just bypass needing to do anything with threads.
>
> It's a little bit different than what I expected and/or am used to.

That kinda sums up the entire "learn to use ASIO" experience for me.  :)

Let us know if you manage to get the tutorial examples running, then
we can work from there.

Good luck!

Best regards,
Anthony Foiani