Re: [asio] using fork in coroutine composed operations

From: Stephan Menzel (stephan.menzel_at_[hidden])
Date: 2019-09-10 05:10:26

Am Di., 10. Sept. 2019 um 02:53 Uhr schrieb Gavin Lambert via Boost-users <
boost-users_at_[hidden]>:

>
> FWIW, your timeout handler if-check is somewhat redundant.
>
> You're capturing the expiry by value (as you have to -- you can't
> capture it by reference since you're moving the lifetime of the timer),
> which means that it will always be less than the current time, unless
> the timer was aborted early due to some error other than operation_aborted.
>
> There isn't any code that can change the expiration time seen by the
> lambda callback (which the comment expresses as the reason for the check).
>
>
Thanks for pointing this out. The code was copy-pasted around much
throughout my efforts and I suppose the comment referred to some other
place where I followed the pattern the asio examples do by re-using the
same timeout again for different ops and reset the expiry time. I will
correct this. You are right. Since it's only used once I don't need the
check, so the comment is wrong.

I'm in the process of creating more such composed ops for ever recurring
use cases and perhaps I find a way to tie this lambdas lifetime to the
whole operation. As it happens, my gut felling tells me there are cases
when the timer lambda will dangle around and potentially crash, perhaps
when the op is used and the io_service being destroyed and not polled
before destruction. I couldn't verify this in the unit test yet but there's
often cases like this that go overlooked.

Cheers,
Stephan