Buffer sequence ownership should be clarified

[pdimov]

At the moment, read_some is specified as

template<MutableBufferSequence Buffers>
IoAwaitable auto read_some(Buffers buffers);

That is, it takes buffers by value.

This doesn't seem correct. It would imply that std::vector<mutable_buffer> is required to be copied by read_some, which is unnecessary.

And if we change this to e.g. Buffers&& buffers, we need to clarify that read_some doesn't mutate buffers in the lvalue case, so that the caller can still use buffers in a subsequent read_some (or write_some) call.

The rvalue case is trickier, but we need to have clarity on #261 before deciding.

[vinniefalco]

Asio requires the following:

"If a read or write operation is also an asynchronous operation, the operation shall maintain one or more copies of the buffer sequence until such time as the operation no longer requires access to the memory specified by the buffers in the sequence."

https://www.boost.org/doc/libs/latest/doc/html/boost_asio/reference/read_write_operations.html

[pdimov]

That's not necessary with coroutines.

[pdimov]

As specified, this also rejects C arrays of mutable_buffer, which seems suboptimal as that's a pretty common use case.

[vinniefalco]

The by-value requirement isn't about the parameter passing convention. It's about the operation maintaining its own copy of the buffer descriptors.

template<MutableBufferSequence MB>
auto read_some(MB buffers)
{
    struct awaitable
    {
        stream* self_;
        MB buffers_;
    };
    return awaitable{this, buffers};
}

The awaitable owns buffers_. Wrap it in a sender:

auto sndr = as_sender(stream.read_some(buf));

The operation state owns the awaitable, the awaitable owns the buffers. Self-contained. Store the sender, move it, let the creating scope end - everything is still valid.

Take by reference and the awaitable holds a pointer back to the caller's buf. Move that sender anywhere and the reference dangles.

"That's not necessary with coroutines" is only true when the awaitable is consumed immediately by co_await in the same scope. The moment it crosses a sender boundary, by-reference breaks.

[pdimov]

That's an interesting point.

Would you be surprised if I told you I care not one bit about senders? That I would not compromise the design for their sake?

[pdimov]

That's an interesting difference between read and read_some, because the former takes the buffer sequence by reference and works with C arrays. (It's not clear whether it's intended to, but it does today.)

If we retain the member read_some behavior, we might want a free function read_some that takes the sequence by reference as read does.

[vinniefalco]

I do care about senders. A little. The possibility of writing a coroutine that receives an HTTP request, and then launches a sender pipeline to run a local inference engine, then resume and send the results back in the HTTP response - this sounds good to me. I think we should not be so quick to dismiss it.

My concern is that Chris K. had a reason for maintaining a copy of the buffer sequence. I agree that it seems unnecessary with coroutines. But who among us has gone astray of the Kohlhoff only to be shown later that he was right, we just didn't know why?

Maintaining a copy of the buffer sequence lets the owner of the value know when the last destructor is called. Its a signal. Do we need this signal anymore? I can't say. Senders does. Maybe that's good enough?