On Mon, Aug 29, 2016 at 4:21 PM, Stephen Day <stevv...@gmail.com> wrote: > 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.
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 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
