net/http: possibly unaligned 64-bit word accessed atomically #33821
Comments
The code in net/http works because the field is comes after an even number of pointers. Same for I'm going to close this issue since there isn't a bug here. |
@ianlancetaylor, sorry I don't get it.
I'm aware of the issues you mentioned. I doubt there's something I haven't read already on the subject, but it's still a big confusion. |
I think that I wasn't thinking when looking at that CL. I agree that I don't see why Brad's change helps the problem. We have a general problem with atomic access to 64-bit words on 32-bit systems, and that needs a general solution. I encourage you to open an issue about that, especially if it is not already covered by the issues I mentioned above. I'm not sure it helps to open an issue about a specific problem in net/http. |
@ianlancetaylor, thanks for the clarification. I can live with the general problem, I'm more concerned about the "clarity" problem. I expected to find 64-bit fields accessed atomically, only at the top of their own struct and well marked; I never suspected a pointer count on 11 fileds was involved.
Well, while we are at it, I think moving It seems far too likely that the next contributor changing EDIT: if |
Here it is.
If I understand the alignment problem correctly, a struct nested in another struct is not by itself "allocated", therefore you cannot assume its first word is 64-bit aligned.
However there is a fair chance that I'm missing something, see the CL. It seems it was done quite on purpose.
If I'm misunderstanding the alignment problem, please close this and I'll file a bug for the
atomic
documentation because the "allocated" wording in theBugs
section is very confusing.Notice that
sync.WaitGroup
goes to all the trouble of making an aligned 64-bit word out of a[3]uint32
usingunsafe.Pointer
, here.Another suspicious 64-bit word accessed atomically is field numClosed in the
DB
struct ofdatabase/sql
. I'm not sure it's safe to assume that its preceding field size is a multiple of 64 bit (interface type).I'm concerned about other cases too. For example I'm not familiar with the
expvar
package, but if a user makes a struct with a field of typeexpvar.Int
(not a pointer), he's going to cause trouble. Is it obvious that you can't do that?The text was updated successfully, but these errors were encountered: