On Sun, Sep 25, 2016 at 8:27 AM, <[email protected]> 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. and messages related to a particular RPC call are sent/received in a > blocking manner > Agreed. 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> . 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 -- 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/CAEOYnAQHh8VG%2BY1tKWVYVbiE5f%2BLkHEwazw7Zu-MakgfGuoBJA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
