Questions on how to switch from an GrpcContext to io_context and back about asio-grpc HOT 6 CLOSED

The good thing about the new asio-grpc APIs new agrpc::ClientRPC, agrpc::Alarm and agrpc::ServerRPC is that you now longer have to bind_executor but you can if you want to switch contexts before completion. In your case however, I do not see a reason to do so. Btw, channels do not create an implicit io_context and you might be able to use agrpc::Alarm to avoid creating one all together.

Assuming that somewhere else in your code:

Channel channel{grpc_context};

and

asio::co_spawn(grpc_context, task(), ...);

Then the context switches would behave as follows:

asio::awaitable<void> task()
{
    // On the GrpcContext's thread
    for (;;) {
        
        // The channel will wait for a message using the GrpcContext's thread (because the grpc_context was passed as argument to the channels constructor. 
        // As soon as one arrives it will switch to the completion handler's executor
        // (the one provided by `use_awaitable` which is the executor that was used in co_spawn'ing this task). 
        // In your case they are the same, so that's a no-op.
        co_await channel.async_receive(use_awaitable);

        // On the GrpcContext's thread

        // Works just fine without binding executor. This will use the GrpcContext's thread to wait for the server's response (because grpc_context is passed as first argument to `request`).
        // As soon as it arrives it will switch to the completion handler's executor
        // (the one provided by `use_awaitable` which is the executor that was used in co_spawn'ing this task). 
        // In your case they are the same, so that's a no-op.
        co_await agrpc::ClientRPC::request(grpc_context, ..., use_awaitable);

        // On the GrpcContext's thread

        // This is a no-op, the first argument and the completion handler's executor are the same.
        co_await asio::post(grpc_context.get_executor(), use_awaitable);

        // On the GrpcContext's thread

        // Same behavior as `async_receive`
        co_await channel.async_send({}, T, use_awaitable);

        // On the GrpcContext's thread
    }
}

When using an implicit io_context created from a GrpcContext, Asio makes sure that user code never runs in the background thread that is created for it. Which means if you wait for a steady_timer for example and it completes, it will first switch to the GrpcContext's thread and then to the completion handler's thread.

from asio-grpc.

Does this mean that agrpc is totally transparent and I never have to switch contexts if I never instantiate the io_context myself? This link states that agrpc will start a background thread to run the implicit io_context. But if I construct all my IO objects with GrpcContext why would it even need an io_context? Which handlers are passed to it? Are those only a subset of Asio IO-objects like socket and timers? I other words, when and how should I interact with the implicit io_context?

from asio-grpc.

It is not agrpc that is transparent, it is Asio itself. It's service makes it possible that any execution_context (like GrpcContext) can be used to construct all of Asio's I/O objects. Depending on the object however, it will end up creating that implicit io_context. I don't know which objects require an io_context exactly, but timers, sockets and signal do. On Linux for example they need to create a file descriptor and poll on it. GrpcContext cannot provide that functionality for them, that's why they create the io_context.

Like I said, the implicit io_context is completely transparent. User code will never be executed on the background thread that it runs on.

from asio-grpc.

Btw, channels do not create an implicit io_context and you might be able to use agrpc::Alarm to avoid creating one all together.

Do you mean a timer? Otherwise I don't see how an Alarm can substitute a asio::channel. Why should I prefer an Alarm over a timer btw?

from asio-grpc.

Yes I meant asio::steady/system_timer. A channel does not create an implicit io_context anyways. Using Alarm over timer might give you a performance benefit: No context switching with the io_context background thread.

from asio-grpc.

Depending on the object however, it will end up creating that implicit io_context.

I was not aware of this, I thought the implicit io_context was being created by asio-grpc.

Thanks.

from asio-grpc.