Behavior of calling (Context).Err without calling (Context).Done

[Stephen Day]

Recently, we were examining some ill-structured code that called (Context).Err() without first calling (Context).Done(). Typically, this seems to return a nil error without any guarantees as to what that means, but this doesn't seem to be called out explicitly.

Should it be required to call Done() before Err()? What should the behavior of Err() called before Done() be in compliant implementations?

I understand the obvious answer is "don't do this", but this seems to be a common mistake and the description of the methods don't make this relationship clear. Is more documentation required?

This came up in the context of this discussion: https://github.com/docker/swarmkit/pull/1437#issuecomment-242892988. The thought was that we could mostly remove the need for a lock on the err field if Done() always provides a barrier. However, incorrect usage of the interface would lead to racy results if the field is unprotected.

Cheers,

Stephen.

[Ian Lance Taylor]

I would be inclined to say that it is a mistake to call Err before the
Done channel is closed. I don't think we have to promise any
particular behavior for that case, but it should not crash and it
should not introduce a race condition.

Ian