Questions on how to switch from an GrpcContext to io_context and back

[criatura2]

In our App we are using an implicitly constructed io_context, which means we only instantiate the agrpc::GrpcContext. Our coroutines (spawned on agrpc::GrpcContext::get_executor()) run both grpc and classical asio tasks like timers and channels.

To ensure we are doing this correctly I would like to ask when and how we should switch executors. For example, suppose we have a coroutine (spawned on agrpc::GrpcContext::get_executor()) that runs the operations in a loop

1. Wait for data from an asio::channel.
2. Perform an agrpc call.
3. Send data over another channel.

Is the following (pseudo) code and comments correct?

asio::awaitable<void> task()
{
    for (;;) {
        
        // Assumes we are on the connect thread. Is this correct?
        co_await channel.async_receive(use_awaitable);

        // Do I have to bind use_awaitable on the grpc_context to do this call or this is ok so?
        co_await agrpc::ClientRP.request(use_awaitable);

        // Is this necessary? Switch back to the io_context thread and only then send into the channel?
        co_await asio::post(grpc_context.get_executor(), use_awaitable);

        // The thread is correct, can perform the call.
        co_await channel.async_send({}, T, use_awaitable);
    }
}

In other works

1. When do I have to bind the grpc_context executor?
2. When should I manually switch threads with asio::post?

Thanks.

[Tradias]

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.

[criatura2]

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?

[Tradias]

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.

[criatura2]

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?

[Tradias]

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.

[criatura2]

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.