Closed tthyer closed 7 years ago
At the moment I have no plans, for two different reasons. First is that it would take basically duplicating all existing methods in this package in order to preserve backwards compatibility, and second (and primarily) is that it wouldn't really work the way someone might like anyway. The net.Conn
type, which is the building block for a redis connection, doesn't support contexts, only read/write timeouts (which this package does export to some extent), so any context support would have to be faked on top of that.
It would be possible to do some "magic" where a Cmd
method returns on context cancel but lets the read/write which was ongoing continue in the background, but this would be fairly hand-wavy and ambiguous. When I see a function which returns when its context is canceled I would assume whatever it was doing is completely done.
In the new radix.v3 I've made most things be interfaces, so it would be possible for someone to implement their own Cmd on top of the existing one and have it support contexts as they see fit. That might be one avenue for further exploration.
TLDR nope, sorry
@mediocregopher, I am very interested in radix.v3, but cannot afford to experiment with it at this point. In the meantime: it is primarily passing a timeout in context that concerns me. It's nice that I'm able to set a timeout on the connection, but I have some use cases where timeout needs to be set per request. Without context, is there a way radix.v2 can do this?
I think that commit will help do what you want. You can set either ReadTimeout or WriteTimeout before performing a Cmd or PipeResp. Just be sure to never set one to zero if was previously not zero.
Do you plan to support context?