On Sun, Jan 15, 2023 at 7:17 AM Klemens Morgenstern via Boost <boost@lists.boost.org> 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.