Late to the party, but ... I have a need for this, so ... On Friday, October 7, 2016 at 6:31:33 AM UTC+11, Nathaniel Manista wrote: > > On Sun, Sep 25, 2016 at 8:27 AM, <[email protected] <javascript:>> > wrote: > >> Nathaniel: That looks like an example of a method implementation. >> > > I think I'm so used to seeing the messages be protocol buffer objects that > I was a simple "item" threw me off. :-P > > >> The stream does not have to be closed explicitly by the implementer >> (though it should be possible to do so). The stream should always close >> when the method returns. The server logic would look something like this: >> >> async def invoke_unary_stream(method, request, reply_stream): >> await method(request, reply_stream) >> if not reply_stream.closed(): >> reply_stream.close() >> >> def handle_unary_stream_request(method, request) -> Tuple[Future, >> ReplyStream]: >> reply_stream = ReplyStream() >> return asyncio.ensure_future(invoke_unary_stream(method, request, >> reply_stream)), reply_stream >> >> >> The reply stream then has to be consumed by either a different coroutine >> or a thread that is responsible for sending response messages. >> >> I have written a simple prototype of an asyncio gRPC implementation in >> hyper-h2 (http://python-hyper.org/projects/h2/en/stable/). I'll be happy >> to put that on GitHub if anyone is interested. >> > > Sure! > > I don't think it is particularly difficult to get gRPC working with >> asyncio in principle. The main issue that needs to be addressed with the >> official gRPC implementation is that there is a thread for each method call >> > > Agreed. >
That's unfortunate. I mean ... that thread could be dealt with in the background, but it's ugly. > and messages related to a particular RPC call are sent/received in a >> blocking manner >> > > Agreed. > Is the existing futures implementation helpful here? in the same thread where the method call is happening. >> > > Are you sure? I think the thread in which the method call is happening is > made to wait > <https://github.com/grpc/grpc/blob/3750af12d9106dce6af1d1cb064f58e9de748b08/src/python/grpcio/grpc/_server.py#L424> > > while the server's own thread sends and receives messages on the wire > <https://github.com/grpc/grpc/blob/3750af12d9106dce6af1d1cb064f58e9de748b08/src/python/grpcio/grpc/_server.py#L647> > . > > It is straightforward to make coroutine method implementation today, but >> the exercise is pointless because each RPC call has its own thread. There >> should be some dedicated threads for receiving and sending messages >> > > Right now there is one dedicated thread (per server) for receiving and > sending messages > <https://github.com/grpc/grpc/blob/3750af12d9106dce6af1d1cb064f58e9de748b08/src/python/grpcio/grpc/_server.py#L727-L729> > . > So, ideally, that thread would either go away and the iomgr would be subsumed by the asyncio event loop (big, hard, and likely ugly) or ... we keep that thread, and have it post events to the event loop (for a received message) and pull send events off a queue? and then a dedicated thread for the event loop. Then handling a request is >> just a matter of invoking the method on the event loop and passing any >> streamed messages between the threads (using a queue or some other >> mechanism). >> > > Sounds reasonable. > -N > Has anything happened here recently? d -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/412fa151-a7f8-4cc9-9fa4-797ebad62e8f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
