GRPC future vs blocking stub in client-CodePudding

I'm writing a client application in Kotlin where I need to call a GRPC service that has both a future based and a blocking stub.

In case I choose to go with the future option, I will need at some point to do something like a CompletableFuture.get() call, which means I will be blocking anyway.

So, what's the difference between one and the other for this case? Or is it the same?

CodePudding user response：

I will need at some point to do something like a CompletableFuture.get() call, which means I will be blocking anyway

Not necessarily. With a ListenableFuture, CompletableFuture, or other completion-hookable mechanisms, you don't have to block at all. You could register an action to do on completion, or you could wrap them in suspend calls to work with coroutines etc.

Also, even if you did call get() and block, it still allows you to block later than the start of the call, and do other things between the initial call and the get(), which would be concurrent with it:

val future = callSomethingWithFuture()
doStuffConcurrently()
val result = future.get()