net/http: possibly unaligned 64-bit word accessed atomically #33821
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
Another suspicious 64-bit word accessed atomically is field numClosed in the
I'm concerned about other cases too. For example I'm not familiar with the
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