Out of curiosity, does having the parsing done in async_exec (vs. in async_run) have to do with making no copies?
Yes, that is the main reason. It reduces latency.
I think I haven't explained myself - I've understood that doing the deserialization in async_run would require copying the data, while doing it in async_exec doesn't. Why?
[...] There is only one corner case where it is received as a push, the SUBSCRIBE command, because it does not have a response. When Redis sends the response I am not expecting any so I must treat it like a push although it has no resp3 push type.
From the discussion, I've got the impression that an application can send regular commands (e.g. SET, GET, and so on) while receiving server pushes (via SUBSCRIBE and async_receive). However, the official docs (https://redis.io/docs/manual/pubsub/) seem to disallow it ("A client subscribed to one or more channels should not issue commands") - it seems to make some exceptions to these, like ping, reset, unsubscribe and further subscribes. Is this true?
b. Can you provide an example of the kind of mistake that would cause this to happen?
request req; req.push("SUBSCRIBE"); // oops, forgot to set a channel.
From the docs again, it seems like you always get a first message stating that you subscribed successfully to that channel, and the number of channels you're currently subscribed to. Would it be possible to parse that as a kind of "subscribe response"? It's currently being handled as a regular push.
Regards, Ruben.