On Tue, 2016-11-29 at 22:46 +0100, Julian Taylor wrote: > On Thu, 24 Nov 2016 11:56:15 +0000 Luca Boccassi > <luca.bocca...@gmail.com> wrote: > > On Thu, 2016-11-24 at 09:58 +0000, PICCA Frederic-Emmanuel wrote: > > > Hello, > > > > > > I just opened a bug for tango > > > > > > https://github.com/tango-controls/cppTango/issues/312 > > > > > > > > > what is the deadline where we can take the decision to upload or not > > > zeromq 4.2.0 into Debian testing ? > > > > > > This will let also some time in order to check if this 4.2.0 do not have > > > other size effect of dependeings softwares. > > > > > > Thanks > > > > > > Fred > > > > Hi, > > > > Thanks for opening a bug upstream. > > > > There is no ABI breakage so there is time for the migration until at > > least the 5th of February. > > > > I see 3 alternatives here: > > > > 1) Upstream fixes it > > 2) A patch to revert the internal buffer alignment is added here > > 3) Ship stretch with 4.1.x > > > > 1 - is of course the preferred way. 2 - is also feasible, but I think > > the consensus upstream is that we don't want to commit to any specific > > guarantee about internal implementation, as it ties down development too > > much. So it would have to be an out-of-tree patch, and I can provide > > that if needed. > > > > The zeromq mailing list is the right place to discuss this if anyone > > strongly disagrees, we are open to have a discussion about anything and > > everything of course. There are differing opinions about these issues > > that range the whole spectrum, from "if users depend on it it's not a > > bug, it's a feature" to "let's break everything everytime", and anywhere > > in between. > > > > I'm doing my best to commit to semantic versioning and API/ABI > > compatibility guarantees, going beyond that is very difficult. > > > > The third option is the worst case scenario. Note that we haven't > > deprecated 4.1.x yet. I wanted to, given it's ABI compatible with 4.2.x, > > but if push came to shove I guess it will have to stay around. > > > > Nitpick, alignment is part of the ABI so it is not compatible.
[CC'ed Jens] Perhaps, but the only guarantee has always been that it would return a void * pointing to contiguous memory, no reference to alignment: http://api.zeromq.org/4-2:zmq-msg-data I realize this is not of much consolation when things break, on the other hand a clear separation of what's internal and what's public is the only way to remain sane I think :-) It would have of course been better to notice immediately, but given it was not part of the public documented api there's no test for it. > But on how to fix this. Given [0] you seem to be just passing out the > pointer to your internal buffer written without padding out to the user > via zmq_msg_data (?) > > The documentation of that function states that you must not access > zmq_msg_t directly, so if nobody actual does do so regardless zmq can > change this structure and stay compatible? > If so can zmq insert alignment padding between the message headers and > the payload so zmq_msg_data returns aligned data? This is an interesting suggestion so I had a look, but unfortunately I don't think it can be done. The pointer returned points directly to the buffer as it was written by the TCP/IPC socket read. Since it's being written as it is received, there is no way at that stage to know what's header and what's payload, and insert padding. The actual decoding of the data is done at a later stage, when it's too late to get away with just adjusting pointers. There are 2 main problems: - socket reads can be interrupted for many reasons and resume, no way to know if what's going to be read is a fresh frame from byte 0 or in the middle of a frame - even ignoring the above problem, the frame header can be either 2 or 9 bytes long, and there's no way to know before reading the first byte As far as I can see the only way would be to change the protocol and have it align the payload on the sender side, but that obviously would be a backward incompatible change which would break every single implementation of ZMTP 3.0, which is a far, far worse outcome. See the RFC, at the "Framing" paragraph: https://rfc.zeromq.org/spec:23/ZMTP/ There is a 3.1 spec in draft state, so perhaps this is a change that could be incorporated there. We do have a way to negotiate the version, so if both peers support 3.1 then perhaps it could be done to add padding. https://rfc.zeromq.org/spec:37/ZMTP > This would be very good for compatibility, on non-x86 arches it might > even be better for performance. Unaligned access can be very slow on > some of the less powerful cpus. > > (Also even on x86 you can get into alignment issues due to these > buffers, in particular with numerical applications where > auto-vectorization by the compilers is involved) > > [0] http://lists.zeromq.org/pipermail/zeromq-dev/2016-November/031096.html Ultimately, performance-wise, this change from Jens allow one less malloc and copy per message (it became effectively a zero-copy receive from the point of view of userspace), and I'd be extremely surprised if the cost of unalignment would out-weight the gains. Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
