[Format] Clarify thread safety of C stream interface

[asfimport]

The C stream interface has the method get_next that mutates the producer side.

We do not mention whether there is some kind of thread safety associated to such interface. For example, can the interface be shared between two threads and both call get_next at the same time?

Reporter: Jorge Leitão / @jorgecarleitao
Assignee: Antoine Pitrou / @pitrou

PRs and other links:

• GitHub Pull Request #12647

_{Note: This issue was originally created as ARROW-15741. Please see the migration documentation for further details.}

[asfimport]

Jorge Leitão / @jorgecarleitao:
@pitrou, thoughts?

[asfimport]

Antoine Pitrou / @pitrou:
I don't think any thread safety can be assumed. If the consumer wants to call get_next from several threads, it should probably ensure all accesses are serialized.

[asfimport]

Antoine Pitrou / @pitrou:
@lidavidm  What do you think?

[asfimport]

David Li / @lidavidm:
I agree with Antoine, we shouldn't assume any thread safety. For instance, what would it do if multiple consumers called it concurrently? Would they each just get a random batch? And even if that's useful semantics, presumably some synchronization would be done internally - at which point, why not just do the synchronization externally?

[asfimport]

Weston Pace / @westonpace:
I agree that we should not allow concurrent calls. I don't think we lose any functionality for this.

A source may be able to be truly accessed in parallel and it may not. For an example of the negative case, if the stream is backed by a TCP socket then calling get_next multiple times is probably useless (we will just block the threads waiting on the socket anyways).

On the other hand, if the stream is a dataset scan on an S3 data source then the source can (and should) be accessing multiple batches of data at once. Instead of allowing multiple calls to get_next the producer should just be configured (external to the stream API) to allow some amount of readahead and the producer should buffer internally.

Note that my opinion is probably heavily influenced by the fact that this is how we handle this problem today.

[asfimport]

Antoine Pitrou / @pitrou:
Issue resolved by pull request 12647
#12647