Comment 1:

What examples are you thinking of, specifically? Closing during a Read or Write?
I'm not sure whether a wide-reaching documentation change is appropriate, or whether a
few select culprits should be better-documented.

Labels changed: added documentation.

Owner changed to a...@golang.org.

Status changed to Accepted.

Comment 2:

I'm specifically thinking of:
   Close during Read or Write
   Read/Write during Read or Write (is Write during Write ok?)
   Close during Accept
Types that I can think of are:
net.IPConn, net.TCPConn, net.UDPConn, net.UnixConn
net.TCPListener, net.UnixListener
io.Pipe
One way of catching all the above with a small change
would be to change the documentation of net.Conn
and net.Listener to explicitly allow concurrent calls,
making it clear that to fit with existing expectations,
any new implementation of net.Conn must allow concurrent
calls.
Then any type implementing Close, for instance,
may document that it is implementing net.Conn.Close,
which implies that it may be called concurrently.
Some types in other packages that might want to document
allowable concurrent method calls:
rpc.Client
netchan.Exporter
http.Client, http.ServerConn, http.ClientConn, ...
reflect.Value
time.Time
Any more?
Some other packages might want some documentation the other way.
It seems that in general it is OK to call package-level
function concurrently. That's not true in all cases
(for instance, the flag package, gob.Register).
Any more of these?
Another area which could probably do with a sentence of annotation
is the sync package - yes, it's "obvious" that it's OK to call
Mutex.Lock concurrently with Mutex.Unlock, but perhaps
it doesn't hurt to state the obvious.

Comment 3:

Labels changed: added priority-later.

Comment 4:

Labels changed: added priority-go1.

Comment 5:

Owner changed to builder@golang.org.

Comment 7:

Labels changed: added go1-must.

Comment 8:

This issue was closed by revision babbf94.

Status changed to Fixed.