wgtmac commented on code in PR #2048:
URL: https://github.com/apache/orc/pull/2048#discussion_r1843136098
##########
c++/include/orc/OrcFile.hh:
##########
@@ -58,6 +73,17 @@ namespace orc {
*/
virtual void read(void* buf, uint64_t length, uint64_t offset) = 0;
+ /**
+ * Read data asynchronously.
+ * @param offset the position in the stream to read from.
+ * @param length the number of bytes to read.
+ * @return a future that will be set to the buffer when the read is
complete.
+ */
+ virtual std::future<BufferPtr> readAsync(uint64_t /*offset*/, uint64_t
/*length*/,
Review Comment:
Do you have the number of the performance penalty?
We need to trade off between performance and usability. In apache/arrow, its
input stream supports both styles of returning a buffer or copying into a
provided buffer. If we need to return a buffer in the readAsync function,
perhaps we need to add an equivalent sync function to return a buffer as well.
> There is an extra advantage if we use the old interface: we could easily
know readAsync is success or not by BufferPtr != nullptr
Isn't an exception expected if the read is unsuccessful?
--
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]
