Hello Sree, Thank you for your suggestion. I sent a PR to update the documentation.
在 2018年8月16日星期四 UTC+8上午3:37:12，Sree Kuchibhotla写道： > > Hi Neil, > To me it sounds very reasonable to expect that if you call > *grpc_call_start_batch* with empty batch, the tag is put in the > completion queue right away (and thereby would kick a thread calling > grpc_completion_queue_next()/pluck() to pick up that tag). > > However, since it is not explicitly documented in the API (in grpc.h), > there is a theoretical possibility that someone might change the > implementation in future to assert a non zero batch size :), I recommend > you to submit a PR by changing the comments of *grpc_call_start_batch *API. > This way, it will have more eyes on the PR and will formalize the contract. > > thanks, > Sree > > > On Thursday, August 9, 2018 at 4:22:02 AM UTC-7, Neil Shen wrote: >> >> I find that if I call `*grpc_call_start_batch*` with an empty batch of >> grpc_op, >> then it will kick its completion queue immediately[1] and the call to >> `grpc_call_start_batch` becomes thread-safe[2] because it does not >> contain any >> send operations or receive operations. >> >> Does it well-document or undefined behavior to start an empty batch? >> >> I am working on grpc-rs[3], a rust implementation, and trying to replace >> alarms >> with calls to kick completion queues. >> >> >> 1: Code about an empty batch, >> >> https://github.com/grpc/grpc/blob/v1.14.1/src/core/lib/surface/call.cc#L1595-L1607 >> >> 2: Quote from grpc.h: >> >> /** Start a batch of operations defined in the array ops; when complete, >>> post a >>> completion of type 'tag' to the completion queue bound to the call. >>> The order of ops specified in the batch has no significance. >>> Only one operation of each type can be active at once in any given >>> batch. >>> If a call to grpc_call_start_batch returns GRPC_CALL_OK you must call >>> grpc_completion_queue_next or grpc_completion_queue_pluck on the >>> completion >>> queue associated with 'call' for work to be performed. If a call to >>> grpc_call_start_batch returns any value other than GRPC_CALL_OK it is >>> guaranteed that no state associated with 'call' is changed and it is >>> not >>> appropriate to call grpc_completion_queue_next or >>> grpc_completion_queue_pluck consequent to the failed >>> grpc_call_start_batch >>> call. >>> THREAD SAFETY: access to grpc_call_start_batch in multi-threaded >>> environment >>> needs to be synchronized. As an optimization, you may synchronize >>> batches >>> containing just send operations independently from batches >>> containing just >>> receive operations. */ >>> GRPCAPI grpc_call_error grpc_call_start_batch(grpc_call* call, >>> const grpc_op* ops, size_t >>> nops, >>> void* tag, void* reserved); >> >> >> 3: https://github.com/pingcap/grpc-rs/ >> > -- 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/fc5a6f12-b6ac-4b15-969d-cf615d32fbfb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
