Re: aedis review starts today

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2023-01-21 14:01:14

> > 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.