New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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: