Why not just use pool.GetContext(ctx)?

@stevenh pool.GetContext(ctx) only get a connection.The ctx will not effect the Do function.

pool := &redis.Pool{}
pool.DialCOntext = func(ctx context.Context){
    return redis.DialContext(ctx,"tcp","127.0.0.1:6379"/*here may be some options like DialReadTimeout*/)
}
func BusinessLogic(ctx context.Context) error{
    c,e:=pool.GetContext(ctx)
    //ctx didn't expired now,i can get the connection
    if e!=nil{
        return e
    }
    //.....here did some other logic
    //then the ctx is expired
    //now call the Do function
    c.Do("SET","test","abc")
    //the Do function will success.
    //because the Do function will use the readtimeout which was setted when the connection was created.but it is 0.
}

1.when a connection create,the connection has 2 timeout,readtimeout and writetimeout,they are setted by DialReadTimeout and DialWriteTimeout
2.when a Do was called,the readtimeout will be used if it is not zero.
3.so the context in pool.GetContext(ctx) will only effect the connection create,it will not effect the command exec.

The comment above the GetContext also said this.
If want to control the command's life,redigo support to use the DoWithTimeout function.But I Think DoContext is more useful then DoWithTimeout

@stevenh can this be merged?The opensource's working efficiency is really a nightmare. 0_0!!!

@stevenh
Cancel context supported.

Any progress on this? It's indeed important :(

My thoughts

Why are we redefining a brand new context cancelation error type: var ErrContextCanceled = errors.New("redis: context canceled")

Can't we use the one from standard library: https://godoc.org/context#pkg-variables

Lots of people like to check the returned error and compare it to the standard library to distinguish between whether the context was cancelled or whether a deadline exceeded.

2. This PR increases the API surface substantially (and in my opinion excessively).

All that is needed is this added to a v2 Conn interface:

func DoContext(ctx context.Context, commandName string, args ...interface{}) (reply interface{}, err error) {

There should be no need for adding timeout/deadline facilities to make it "appear" more convenient for developers.
Developers can easily do it themselves via the context package.

Alternatively, Conn2 interface can be defined which embeds Conn interface.

I think maintainer wants to go in this direction: #351

Ah, I think I should consider using github.com/go-redis/redis instead :)

Ah, I think I should consider using github.com/go-redis/redis instead :)

Is there something that is missing that is driving that comment?

@stevenh @NitroCao @pjebs @ash2k
sorry guys,work and life have some change,i will find some time to fix the comments,but it may have some delay

@pjebs @stevenh already changed context error to std lib's error.
test file fixed too

Any updates on this? We would really like to use this library in our Thola project, but Context support is critical for us.

@TheFireMike this is now merged, sorry I'm not been getting some github emails, so didn't realise this was now complete.

Thanks to everyone for their contributions to this PR.

may i ask, why i cant find DoContext in the current realease (v1.8.5)?

It was merged after v1.8.5.

I've just created v1.8.6

this is awesome, thank you very much