lidavidm commented on code in PR #36205: URL: https://github.com/apache/arrow/pull/36205#discussion_r1243867859
########## TODOs.txt: ########## @@ -0,0 +1,17 @@ +- Use a uniform API for all async Flight client APIs: + + void Foo(const FlightCallOptions&, shared_ptr<ReadListener<T>> listener); + + - shared_ptr, or raw pointer? (gRPC uses the latter...) Review Comment: Hmm, the problem is then we have a circular reference (and weak_ptr just punts the problem). The caller has state (the callbacks), and the transport has state (the actual RPC), and they both need to reference each other (the callbacks need to update the transport, and the transport needs to invoke the callbacks). I suppose we could very carefully drop the weak/shared_ptr holding the callbacks from the RPC state when the RPC finishes, breaking the loop...? But I would rather not create the situation in the first place. For what it's worth, the gRPC API expects the caller to hold the RPC state alive (that's the grpc::ClientContext). I suppose a different solution would be to force the transport to hold all the state (e.g. by stashing it in the client object). This makes the client worse for concurrent RPCs (now they're all blocking on that central state, even if only for a short time). Another might be to change the return type from `void` to some object containing the RPC state. The caller would then hold this alive (and internally it would own the callbacks). You would still have to heap-allocate the callback structure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
