gRPC CompletionQueue是否遵循FILO规则?附异步客户端代码疑问
gRPC CompletionQueue: Is It a FILO Structure?
Short answer: No, gRPC's CompletionQueue is a FIFO (First-In-First-Out) queue, not FILO.
Let me break this down clearly for you:
- By design, the CompletionQueue’s core purpose is to deliver RPC completion events in the order they become ready (or more precisely, the order completed events are enqueued). When you call
CompletionQueue::Next()orAsyncNext()to pull events, you’ll always get the earliest completed event first. - Taking your async client code snippet as an example: when you create an RPC via
stub_->PrepareAsyncSayHello()and register its completion with the queue, once that RPC finishes (e.g., the server response comes back), it’s added to the queue. If you have multiple RPCs running in parallel, the one that finishes first will be the first picked up by your event loop—regardless of which was initiated last. - You might occasionally see behavior that looks like FILO (e.g., a later-started RPC finishes before an earlier one), but that’s due to network latency or server-side processing order, not the CompletionQueue itself. The queue’s underlying implementation strictly uses FIFO logic to manage pending completion events.
In the greeter_async_client.cc example you referenced, the event loop processes responses exactly in the order they complete, which directly reflects the CompletionQueue’s FIFO nature.
内容的提问来源于stack exchange,提问作者Di Zhong
相关产品推荐
相关产品推荐

