Re: aedis review starts today

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2023-01-19 17:32:03

On Sun, Jan 15, 2023 at 7:17 AM Klemens Morgenstern via Boost
<boost_at_[hidden]> wrote:
> The formal review of the aedis starts today (15th) and ends next week on
> Tuesday (24th).

I have questions too

1. From what I gathered from docs and source code, connection
implements a queue where requests
    are placed before sending. async_exec puts/pops from the queue,
and async_run does the actual I/O.
    The benefits being you can call async_exec without the usual
restriction of "single outstanding operation"
    that Beast and MySQL impose. Is that right?
2. If there are write errors in a request, it is async_run, and not
async_exec, the function that gets the error
    is async_run, and not the individual requests queued by async_exec. Right?
3. If a server push is received but no async_receive is outstanding,
according to docs, "the connection will hang".
    Does that mean that any responses to other requests I wrote with
async_exec will not complete until
    I call async_receive (so I can expect a deadlock there)?
    Also, I can see there is a heuristic rule to determine what is a
server push response and what is not,
    how does this interact with my comment above?
4. From what I've gathered, the protocol can be made full duplex (you
may write further requests while reading
    responses to previously written requests), but the queue acts as
half-duplex (it won't write a batch
    until the response to the previous batch has been completely
read). This can be circumvented using the low-level
    API. Am I getting the picture right? Or are there further protocol
limitations I'm not aware of?
5. Merging async_run into async_exec and async_receive is possible but
we lack the implementation tools
    required (namely Klemens' asem async synchronization primitives).
You mention that there would be a
    performance loss, why?
6. From the implementation, I've seen every request allocates a new
asio timer, I'd say for communication between
    the async_exec and async_receive tasks. Is allocating those I/O
objects cheap?
7. There is no sync counterpart to async_receive, async_exec and
async_run, which is unusual in Asio-based
    libraries - is that intentional?
8. Docs state that async_run "will trigger the write of all requests
i.e. calls to async_exec that happened prior to this call".
    I assume it will also write requests that are queued while
async_run is in progress, right?
9. What is the recommended way of using async_run, async_exec and
async_receive together with multi-threading?
    Would using a basic_stream_socket<ip::tcp, strand> as
AsyncReadWriteStream be enough?
10. From what I've seen, all tests are integration tests, in that they
test with an actual Redis instance.

Regards,
Ruben.