ARROW-8311: [C++] Add push style stream format reader #6804

kou · 2020-04-02T03:19:01Z

This change adds the following push style reader classes:

ipc::MessageEmitter
ipc::RecordBatchStreamEmitter

Push style readers don't read data from stream directly. They receive
already read data by users. This style is useful with event driven
style IO API. We can't read data from stream directly in event driven
style IO API. We just receive already read data from event driven style
IO API like:

void on_read(const uint8_t* data, size_t data_size) {
   process_data(data, data_size);
}
register_read_event(on_read);
run_event_loop();

We can't use the current reader API with event driven style IO API but
we can use this push style reader with event driven style IO API.

The current Message reader is changed to use ipc::MessageEmitter
internally. So we don't have duplicated reader implementation. And no
performance regression with our benchmark.

Before:

Running release/arrow-ipc-read-write-benchmark
Run on (12 X 4600 MHz CPU s)
CPU Caches:
  L1 Data 32K (x6)
  L1 Instruction 32K (x6)
  L2 Unified 256K (x6)
  L3 Unified 12288K (x1)
Load Average: 0.85, 0.84, 0.65
-----------------------------------------------------------------------------------------
Benchmark                               Time             CPU   Iterations UserCounters...
-----------------------------------------------------------------------------------------
ReadRecordBatch/1/real_time           886 ns          886 ns       774286 bytes_per_second=1102.15G/s
ReadRecordBatch/4/real_time          1601 ns         1601 ns       436258 bytes_per_second=610.078G/s
ReadRecordBatch/16/real_time         4819 ns         4820 ns       143568 bytes_per_second=202.663G/s
ReadRecordBatch/64/real_time        18291 ns        18296 ns        38586 bytes_per_second=53.3893G/s
ReadRecordBatch/256/real_time       84852 ns        84872 ns         8317 bytes_per_second=11.5091G/s
ReadRecordBatch/1024/real_time     341091 ns       341168 ns         2049 bytes_per_second=2.86306G/s
ReadRecordBatch/4096/real_time    1368049 ns      1368361 ns          511 bytes_per_second=730.968M/s
ReadRecordBatch/8192/real_time    2676778 ns      2677341 ns          265 bytes_per_second=373.584M/s

After:

Running release/arrow-ipc-read-write-benchmark
Run on (12 X 4600 MHz CPU s)
CPU Caches:
  L1 Data 32K (x6)
  L1 Instruction 32K (x6)
  L2 Unified 256K (x6)
  L3 Unified 12288K (x1)
Load Average: 0.88, 0.85, 0.66
-----------------------------------------------------------------------------------------
Benchmark                               Time             CPU   Iterations UserCounters...
-----------------------------------------------------------------------------------------
ReadRecordBatch/1/real_time           891 ns          891 ns       769579 bytes_per_second=1095.57G/s
ReadRecordBatch/4/real_time          1599 ns         1599 ns       435756 bytes_per_second=610.746G/s
ReadRecordBatch/16/real_time         4834 ns         4835 ns       144374 bytes_per_second=202.027G/s
ReadRecordBatch/64/real_time        18204 ns        18206 ns        38190 bytes_per_second=53.6465G/s
ReadRecordBatch/256/real_time       84142 ns        84154 ns         8309 bytes_per_second=11.6061G/s
ReadRecordBatch/1024/real_time     343105 ns       343148 ns         2035 bytes_per_second=2.84625G/s
ReadRecordBatch/4096/real_time    1399287 ns      1399484 ns          511 bytes_per_second=714.65M/s
ReadRecordBatch/8192/real_time    2641529 ns      2641845 ns          263 bytes_per_second=378.569M/s

github-actions · 2020-04-02T03:31:28Z

https://issues.apache.org/jira/browse/ARROW-8311

pitrou · 2020-04-02T11:29:33Z

Thank you. I think that we should get the API as general as possible, so I would suggest the following:

class ARROW_EXPORT Receiver {
 public:
  // Subclasses should override the methods they're interested in.
  // Default implementations return NotImplemented.
  virtual Status RecordBatchReceived(std::shared_ptr<RecordBatch>);
  virtual Status TensorReceived(std::shared_ptr<Tensor>);
  virtual Status SparseTensorReceived(std::shared_ptr<SparseTensor>);
};

pitrou · 2020-04-02T11:30:12Z

(this will also be useful for Flight @lidavidm )

lidavidm · 2020-04-02T12:23:20Z

This will be very useful! Once this lands I'll see about wiring this up to the gRPC async APIs.

kou · 2020-04-03T00:28:55Z

@pitrou Thanks for the suggestion! It's a good idea.
I've added a arrow::Reciver only with MessageReceived() and RecordBatchReceived(). We can add more XXXReceived() when we need.

kou · 2020-04-03T00:39:57Z

@lidavidm Thanks! I can help you when you work on it.

The code will look like the followings:

void on_read(const uint8_t* data, size_t data_size) {
  std::shared_ptr<Buffer> chunk;
  arrow::Buffer(data, data_size).Copy(0, data_size, &chunk);
  emitter_.Consume(chunk);
  while (!chunks_.empty()) {
    if (chunks_[0].use_count() > 1) {
      break;
    }
    chunks_.erase(chunks_.begin());
  }
  if (chunk.use_count() > 1) {
    chunks_.push_back(std::move(chunk));
  }
}

wesm · 2020-04-07T01:17:05Z

Sorry about not reviewing this yet, it's on my "short list".

pitrou · 2020-04-07T09:48:17Z

Thanks for the update @kou.

I don't think it makes sense to have both MessageReceived and RecordBatchReceived, since message and record batch are different levels of abstraction. I don't see how MessageReceived can be useful, to be honest (do you expect the consumer to reimplement message decoding?).

Once we agree on the basic abstraction, I will make a more thorough review.

kou · 2020-04-07T21:22:00Z

I thought you suggested that we add a general receiver API like existing arrow::Iterator instead of multiple receiver APIs for each received object. I thought that it's a good idea because it simplifies our API.

If we have a receiver API for arrow::ipc::Message and a receiver API for arrow::RecordBatch, arrow::Tensor, arrow::SparseTensor and so on. I prefer receiver APIs for each object (MessageReceiver, RecordBatchReceiver and so on) to two receiver APIs (for arrow::ipc::Message and for others). If we have receiver APIs for each object, users can detect "forget to implement" error on compile time because we can provide an abstract receiver class with virtual Status Received(...) = 0.

We don't have data format that mixes RecordBatch, Tensor and SparseTensor for now. Users will want to implement one Received() API for most case. Compile time error detection will help users.

I don't see how MessageReceived can be useful, to be honest (do you expect the consumer to reimplement message decoding?).

This pull request implements the following push style readers:

arrow::ipc::MessageEmitter for arrow::ipc::Message
arrow::ipc::RecordBatchStreamEmitter for arrow::RecordBatch

arrow::ipc::RecordBatchStreamerEmitter is implemented with arrow::ipc::MessageEmitter. arrow::ipc::MessageEmitter uses MessageReceived API.

For arrow::Tensor, we don't have convenience API to read multiple arrow::Tensors. We need to call arrow::ipc::ReadTensor() multiple times but this is not push style:

while (true) {
  auto tensor = arrow::ipc::ReadTensor(input);
  if (!tensor.status().ok()) {
    break; // tensor.status() will be arrow::Status::Invalid
   }
  // process tensor
}

Users can implement push style arrow::Tensor reader with MessageReceived API (I think that we provide a convenient API instead if this use case makes sence):

class TensorProcessor : public arrow::Receiver {
  arrow::Status MessageReceive(arrow::unique_ptr<Message> message) override {
    ARROW_ASSIGN_OR_RAISE(auto tensor, arrow::ipc::ReadTensor(*message));
   // process tensor
  }
};

TensorProcesor processor;
arrow::ipc::MessageEmitter emitter(&processor);
while (emitter.state() != arrow::ipc::MessageEmitter::State::EOS) {
  emitter.Consume(data, data_size);
}

Normally, users should not use MessageReceived API because this arrow::ipc::Message is a low level object. Advanced users may use it.

Do you prefer the following API?

// only for arrow::ipc::Message
class ARROW_EXPORT MessageReceiver {
  virtual Status Receive(std::unique_ptr<Message> message) = 0;
};

// for others
class ARROW_EXPORT Receiver {
  // Default implementations return NotImplemented.
  virtual Status RecordBatchReceived(std::shared_ptr<RecordBatch> record_batch);
  virtual Status TensorReceived(std::shared_ptr<Tensor> tensor);
  virtual Status SparseTensorReceived(std::shared_ptr<SparseTensor> tensor);
};

pitrou · 2020-04-07T22:21:41Z

Do you prefer the following API? [snip]

Yes. This is what I meant. Either you decode messages yourself and you implement MessageReceiver, or you let Arrow decode them and you implement Receiver.

kou · 2020-04-08T00:28:55Z

OK. I've changed to use the API.

wesm · 2020-04-08T01:45:32Z

I started reviewing, will try to finish soon

wesm

Overall this looks good, thanks for working on this -- I think this will make it easier to implement delta dictionaries and dictionary replacements. Some minor stylistic comments

cpp/src/arrow/ipc/message.h

wesm · 2020-04-08T02:14:39Z

cpp/src/arrow/ipc/message.h

The meaning of this parameter is not totally clear. Maybe "the number of bytes needed"?

Yes.
I've changed to use "the number of bytes needed" for description.
Should we also improve parameter name (next_required_size)?

wesm · 2020-04-08T02:15:36Z

cpp/src/arrow/ipc/message.h

Does this function need to retain ownership of the Buffer (versus const Buffer&)

Yes.
If the given buffer doesn't have enough data, emitter keeps the buffer in chunks_ instead of using it immediately. If we doesn't retain ownership of the given buffer, the buffer may be destructed when emitter uses it.

cpp/src/arrow/ipc/read_write_benchmark.cc

wesm · 2020-04-08T02:35:44Z

cpp/src/arrow/util/receiver.h

Style choice: We could use the same function name for all the receivers, like Receive, but with different input argument types. Not sure if all compilers would be happy about that.

You mean the following API, right?

class ARROW_EXPORT Receiver { virtual Status Received(std::shared_ptr<RecordBatch> record_batch); virtual Status Received(std::shared_ptr<Tensor> tensor); virtual Status Received(std::shared_ptr<SparseTensor> sparse_tensor); };

I don't have a preference for this.

@pitrou What do you think about this API?

No preference, but Received alone sounds weird.

We can't use this API if we use Receiver::EosReceived(). Because EosReceived() has no argument.

cpp/src/arrow/util/receiver.h

cpp/src/arrow/ipc/message.cc

kou

@wesm Thanks for your review!
I've fixed most of problems.
What do you think about next_required_size name?

cpp/src/arrow/ipc/message.cc

cpp/src/arrow/ipc/message.h

kou · 2020-04-08T05:35:11Z

cpp/src/arrow/ipc/message.h

Yes.
I've changed to use "the number of bytes needed" for description.
Should we also improve parameter name (next_required_size)?

kou · 2020-04-08T05:37:31Z

cpp/src/arrow/ipc/message.h

Yes.
If the given buffer doesn't have enough data, emitter keeps the buffer in chunks_ instead of using it immediately. If we doesn't retain ownership of the given buffer, the buffer may be destructed when emitter uses it.

cpp/src/arrow/ipc/read_write_benchmark.cc

cpp/src/arrow/util/receiver.h

kou · 2020-04-08T05:49:33Z

cpp/src/arrow/util/receiver.h

You mean the following API, right?

class ARROW_EXPORT Receiver { virtual Status Received(std::shared_ptr<RecordBatch> record_batch); virtual Status Received(std::shared_ptr<Tensor> tensor); virtual Status Received(std::shared_ptr<SparseTensor> sparse_tensor); };

I don't have a preference for this.

@pitrou What do you think about this API?

pitrou

I'm still only looking at the API.

pitrou · 2020-04-08T08:54:03Z

cpp/src/arrow/ipc/reader.h

I would call this StreamDecoder or something. At some point we'll add other methods to Receiver, so it won't emit just record batches.

OK. I'll rename this to arrow::ipc::StreamDecoder.

You mean that we will extend https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format later to support more data type such as tensor. Right?

Right, we would add TensorReceived (or OnTensor or whatever the chosing naming is :-)).

cpp/src/arrow/ipc/reader.h

pitrou · 2020-04-08T08:55:40Z

cpp/src/arrow/ipc/reader.h

Instead this could be a EosReceived method on Receiver or something.
(note: the terminology I'm proposing is inspired by https://docs.python.org/3/library/asyncio-protocol.html#streaming-protocols , but YMMV)

I'll add Receiver::EosReceived() and remove is_eos().

pitrou · 2020-04-08T08:56:10Z

cpp/src/arrow/ipc/reader.h

I don't understand what this means. What is the next action?

I think it's "advancing the state of the emitter". So if you just read the metadata size prefix then this would return the size of the metadata, or the size of the body

Does it mean you're expected to give exactly that number of bytes to Consume? Or does the emitter do its own buffering inside? The docs should probably make that clear.

If you feed the emitter too much data, it will retain a slice of it internally, yes. This can be made more clear in the docs indeed

I'll add more documentations. Could you confirm it?

cpp/src/arrow/ipc/reader.h

wesm · 2020-04-08T12:36:17Z

cpp/src/arrow/ipc/message.h

The name of this function is okay with me

kou

@pitrou Thanks for your review!
I've applied your suggestion except StreamDecoder. I want to confirm what you meant.

kou · 2020-04-08T20:41:07Z

cpp/src/arrow/ipc/reader.h

OK. I'll rename this to arrow::ipc::StreamDecoder.

You mean that we will extend https://arrow.apache.org/docs/format/Columnar.html#ipc-streaming-format later to support more data type such as tensor. Right?

cpp/src/arrow/ipc/reader.h

kou · 2020-04-08T22:08:17Z

cpp/src/arrow/ipc/reader.h

I'll add more documentations. Could you confirm it?

kou · 2020-04-08T22:16:40Z

cpp/src/arrow/ipc/reader.h

I'll add Receiver::EosReceived() and remove is_eos().

kou · 2020-04-08T22:17:48Z

cpp/src/arrow/util/receiver.h

We can't use this API if we use Receiver::EosReceived(). Because EosReceived() has no argument.

wesm · 2020-04-08T22:55:30Z

Bunch of CI jobs failed with "no space left on device".

Overall this patch looks good to me. I'll await @pitrou to make a final review / sign off per the comments above

kou · 2020-04-09T02:19:34Z

If we may have any not-received callback such as a callback that is called on error and a callback that is called on dictionary updated, Listener may be better than Receiver.
If we use Listener, On${Event} will be better than ${Target}Received such as Listener::OnRecordBatch() (or Listner::OnRecordBatchReceived()?) and Listener::OnError().

pitrou

I'll let @wesm comment on the naming.

High-level question: is it possible to reimplement RecordBatchStreamReader and MessageReader on top of this infrastructure? It's not terrific to duplicate the decoding logic in several places.

pitrou · 2020-04-09T10:06:48Z

cpp/src/arrow/ipc/message.h

Instead of this, I think it would be better to have an EosReceived method on MessageReceiver.

I've added EOS callback but I want to keep this method.
Because this information can be used to optimize performance. I've added documentation for this.

wesm · 2020-04-09T15:41:11Z

I'm looking again. This needs to be rebased now after ARROW-7233, I'll see if I can perform the rebase

wesm · 2020-04-09T16:22:56Z

High-level question: is it possible to reimplement RecordBatchStreamReader and MessageReader on top of this infrastructure? It's not terrific to duplicate the decoding logic in several places.

Unless I'm missing something, that's exactly what this patch does. MessageReader just calls ReadMessage(InputStream*) which uses RecordBatchStreamEmitter

I'm looking at the other naming issues

wesm · 2020-04-09T16:44:35Z

Assorted thoughts:

We should probably mark these new APIs as experimental so we do not feel pressure to resolve all concerns in a single patch
arrow/util/receiver.h should probably be part of arrow/ipc
I don't have a strong opinion between Receiver and Listener name

pitrou · 2020-04-09T17:08:16Z

It seems MessageReader calls the top-level ReadMessage(io::InputStream* file, MemoryPool* pool) for each message... which will instantiate a new Emitter and Receiver every time.

wesm · 2020-04-09T17:24:56Z

I agree it would be good to improve that (persisting the emitter between calls to ReadNextMessage)

pitrou · 2020-04-09T22:17:34Z

By the way, since this is a new API, perhaps it should incorporate per-message metadata as well? (the custom_metadata field). For example:

virtual Status RecordBatchReceived(
  std::shared_ptr<RecordBatch> record_batch,
  std::shared_ptr<KeyValueMetadata> custom_metadata);
virtual Status SchemaReceived(
  std::shared_ptr<Schema> schema,
  std::shared_ptr<KeyValueMetadata> custom_metadata);

This change adds the following push style reader classes: * ipc::MessageEmitter * ipc::RecordBatchStreamEmitter Push style readers don't read data from stream directly. They receive already read data by users. This style is useful with event driven style IO API. We can't read data from stream directly in event driven style IO API. We just receive already read data from event driven style IO API like: void on_read(const uint8_t* data, size_t data_size) { process_data(data, data_size); } register_read_event(on_read); run_event_loop(); We can't use the current reader API with event driven style IO API but we can use this push style reader with event driven style IO API. The current Message reader is changed to use ipc::MessageEmitter internally. So we don't have duplicated reader implementation. And no performance regression with our benchmark. Before: Running release/arrow-ipc-read-write-benchmark Run on (12 X 4600 MHz CPU s) CPU Caches: L1 Data 32K (x6) L1 Instruction 32K (x6) L2 Unified 256K (x6) L3 Unified 12288K (x1) Load Average: 0.85, 0.84, 0.65 ----------------------------------------------------------------------------------------- Benchmark Time CPU Iterations UserCounters... ----------------------------------------------------------------------------------------- ReadRecordBatch/1/real_time 886 ns 886 ns 774286 bytes_per_second=1102.15G/s ReadRecordBatch/4/real_time 1601 ns 1601 ns 436258 bytes_per_second=610.078G/s ReadRecordBatch/16/real_time 4819 ns 4820 ns 143568 bytes_per_second=202.663G/s ReadRecordBatch/64/real_time 18291 ns 18296 ns 38586 bytes_per_second=53.3893G/s ReadRecordBatch/256/real_time 84852 ns 84872 ns 8317 bytes_per_second=11.5091G/s ReadRecordBatch/1024/real_time 341091 ns 341168 ns 2049 bytes_per_second=2.86306G/s ReadRecordBatch/4096/real_time 1368049 ns 1368361 ns 511 bytes_per_second=730.968M/s ReadRecordBatch/8192/real_time 2676778 ns 2677341 ns 265 bytes_per_second=373.584M/s After: Running release/arrow-ipc-read-write-benchmark Run on (12 X 4600 MHz CPU s) CPU Caches: L1 Data 32K (x6) L1 Instruction 32K (x6) L2 Unified 256K (x6) L3 Unified 12288K (x1) Load Average: 0.88, 0.85, 0.66 ----------------------------------------------------------------------------------------- Benchmark Time CPU Iterations UserCounters... ----------------------------------------------------------------------------------------- ReadRecordBatch/1/real_time 891 ns 891 ns 769579 bytes_per_second=1095.57G/s ReadRecordBatch/4/real_time 1599 ns 1599 ns 435756 bytes_per_second=610.746G/s ReadRecordBatch/16/real_time 4834 ns 4835 ns 144374 bytes_per_second=202.027G/s ReadRecordBatch/64/real_time 18204 ns 18206 ns 38190 bytes_per_second=53.6465G/s ReadRecordBatch/256/real_time 84142 ns 84154 ns 8309 bytes_per_second=11.6061G/s ReadRecordBatch/1024/real_time 343105 ns 343148 ns 2035 bytes_per_second=2.84625G/s ReadRecordBatch/4096/real_time 1399287 ns 1399484 ns 511 bytes_per_second=714.65M/s ReadRecordBatch/8192/real_time 2641529 ns 2641845 ns 263 bytes_per_second=378.569M/s Fix format Fix lint errors Fix lint errors Fix sanitizer errors Use AllocateBuffer to create empty 64-bit aligned buffer Introduce general Receiver API Add missing include Fix error type Use new Receiver API Fix format Split MessageReceiver again Remove duplicated comments Fix style Don't use deprecated API Don't use deprecated API Add missing slice for non CPU buffer Fix next_required_size parameter description Use ABORT_NOT_OK() Remove needless forward declaration Use different test suite name Fix include location Fix a bug that next_required_size() doesn't care buffered_size_ Use std::shared_ptr<Receiver> Add SchemaReceived Add more documentation for next_required_size() Use EosReceived() instead of is_eos() Rebase Remove unused variable from test

kou

I've applied all suggestions except per-message metadata.

Summary:

Renamed emitter to decoder
Marked new APIs experimental
Moved Receiver from arrow/util to arrow/ipc
Renamed Receiver to Listener
MessageReader reuses decoder

For per-message metadata, I'm not sure which message's metadata is used when any dictionary batch message exists. Schema message's metadata? Should we merge all metadata in schema message and dictionary batch messages?

Can we do it as a follow-up task?

For RecordBatchStreamReader, we can't use StreamDecoder in RecordBatchStreamReader internally. Because we have RecordBatchStreamReader::Open(std::unique_ptr<MessageReader> message_reader, ...) API. If we use StreamDecoder, we don't use MessageReader.
(We can use StreamDecoder with this API by extracting InputStreamMessageReader::stream_ from MessageReader and creating StreamDecoder from the extracted stream. Should we do this?)

Most of core logics are shared with RecordBatchStreamReader and StreamDecoder in this pull request. Should we reimplement RecordBatchStreamReader by StreamDecoder in this pull request? Or can we do it as a follow-up task?

kou · 2020-04-10T00:31:03Z

cpp/src/arrow/ipc/message.h

I've added EOS callback but I want to keep this method.
Because this information can be used to optimize performance. I've added documentation for this.

wesm · 2020-04-10T00:58:40Z

Thank you @kou

For per-message metadata, I'm not sure which message's metadata is used when any dictionary batch message exists. Schema message's metadata? Should we merge all metadata in schema message and dictionary batch messages?

My initial thought was that we should only propagate the metadata from the Message::custom_metadata field, but you're right that it's unclear what to do with any metadata from a DictionaryBatch message. Let's think a bit more about it -- since the APIs are experimental we don't have to figure this out right now

wesm · 2020-04-10T15:19:45Z

+1, merging. The CI failure https://github.com/apache/arrow/pull/6804/checks?check_run_id=575674263 does not appear to be related to me

wesm self-requested a review April 2, 2020 17:27

pitrou self-requested a review April 3, 2020 11:57

kou force-pushed the cpp-record-batch-emitter branch from d46b706 to 6784278 Compare April 3, 2020 22:14

kou force-pushed the cpp-record-batch-emitter branch from 6784278 to b31977d Compare April 7, 2020 21:53

wesm mentioned this pull request Apr 8, 2020

ARROW-7233: [C++] Use Result<T> in remaining value-returning IPC APIs #6867

Closed

wesm reviewed Apr 8, 2020

View reviewed changes

kou commented Apr 8, 2020

View reviewed changes

pitrou reviewed Apr 8, 2020

View reviewed changes

wesm reviewed Apr 8, 2020

View reviewed changes

cpp/src/arrow/ipc/message.h Outdated

Copy link

Member

wesm Apr 8, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name of this function is okay with me

kou commented Apr 8, 2020

View reviewed changes

pitrou reviewed Apr 9, 2020

View reviewed changes

wesm force-pushed the cpp-record-batch-emitter branch from 9e280d0 to 247e118 Compare April 9, 2020 16:18

wesm force-pushed the cpp-record-batch-emitter branch from b23a193 to f80f953 Compare April 9, 2020 16:42

kou added 10 commits April 10, 2020 09:24

Add explicit std::move()

20b0aac

Rename to "decoder" from "emitter"

76e7aba

Move Receiver from arrow/util/ to arrow/ipc/

230cd0b

Mark new APIs as experimental

cc6da56

Use decode

a9629a2

Rename MessageReceiver to MessageDecoderListener

b4fd9cc

Reuse decoder in MessageReader

9a04e96

Format

a5d7320

Rename receiver to listener

7fab0e3

kou force-pushed the cpp-record-batch-emitter branch from f80f953 to 7fab0e3 Compare April 10, 2020 00:25

kou commented Apr 10, 2020

View reviewed changes

kou added 2 commits April 10, 2020 09:47

Add missing std::move()

2592504

Suppress warnings

7bcc20e

wesm closed this in 866e6a8 Apr 10, 2020

kou deleted the cpp-record-batch-emitter branch April 10, 2020 22:09

asfimport mentioned this pull request Apr 10, 2020

[C++] Add push style stream format reader #24500

Closed

ARROW-8311: [C++] Add push style stream format reader #6804

ARROW-8311: [C++] Add push style stream format reader #6804

Uh oh!

Conversation

kou commented Apr 2, 2020

Uh oh!

github-actions bot commented Apr 2, 2020

Uh oh!

pitrou commented Apr 2, 2020

Uh oh!

pitrou commented Apr 2, 2020

Uh oh!

lidavidm commented Apr 2, 2020

Uh oh!

kou commented Apr 3, 2020

Uh oh!

kou commented Apr 3, 2020

Uh oh!

wesm commented Apr 7, 2020

Uh oh!

pitrou commented Apr 7, 2020

Uh oh!

kou commented Apr 7, 2020

Uh oh!

pitrou commented Apr 7, 2020

Uh oh!

kou commented Apr 8, 2020

Uh oh!

wesm commented Apr 8, 2020

Uh oh!

wesm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

kou left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pitrou left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kou left a comment •

edited

Loading

wesm commented Apr 8, 2020 •

edited

Loading