Replies: 1 comment
-
I've done a bit of history digging:
In the commit for the doc change, even thought it's not for the message queue but memory slab, we find the string "ZEP-1265". And thankfully it's imported to the github as the issue #2747. The issue says that it was Arc which failed with unaligned access. I agree that Looking forward to someone who knows the history to jump in. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I posted this on Slack a while ago, but I figured this discussion would be better somewhere a little more accessible.
I've been comparing the Message Queue documentation to the implementation and some of the usage prescriptions seem a bit off.
In particular, the documentation for the message queue states:
And the Data Passing table on the Kernel Services documentation page summarizes:
Discounting the liberal interpretation of 2^0 = 1, which would effectively be the same as not having any alignment or size restrictions, it seems to me like these restrictions don't quite make sense given the implementation.
Looking at the source implementation in msg_q.c, all access to the ring buffer contents is done through
memcpy()
. My understanding ofmemcpy()
is that it should work correctly regardless of the alignment of the source or destination, though it may be slower when operating on a source or destination that are not aligned to the CPU's native word size.Based on this, I think it doesn't really make sense to frame the alignment requirements as being related to a power-of-two at all. Instead, I think that the size and alignment can be documented as "arbitrary" with a footnote that performance may be degraded if the alignment and size are not a multiple of the native word size.
Beta Was this translation helpful? Give feedback.
All reactions