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. 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 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
