Giter VIP home page Giter VIP logo

Comments (6)

Tradias avatar Tradias commented on July 24, 2024

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.

criatura2 avatar criatura2 commented on July 24, 2024

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.

Tradias avatar Tradias commented on July 24, 2024

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.

criatura2 avatar criatura2 commented on July 24, 2024

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.

Tradias avatar Tradias commented on July 24, 2024

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.

criatura2 avatar criatura2 commented on July 24, 2024

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.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.