On Tue, 2016-09-27 at 09:41 +0300, Doron Somech wrote:
> Sorry for the late response, increasing the msg_t structure will be
> great, however this will require changing a lot of binding.
I think I remember we need it for the new socket types, is that correct?
There is a large performance penalty (intuitively due to not fitting
into a single cache line anymore, but haven't ran perf/cachegrind), and
the throughput with vsm type messages goes down by 4% (min) and 20%
(max) for TCP, and 36% (min) 38 (max) for inproc, which is quite a lot,
so we need to be sure it's worth it.
Regarding the bindings, after a quick search on the Github org, I could
only see:
https://github.com/zeromq/lzmq/blob/master/src/lua/lzmq/ffi/api.lua#L144
https://github.com/zeromq/clrzmq4/blob/master/lib/zmq.cs#L28
https://github.com/zeromq/pyczmq/blob/master/pyczmq/zmq.py#L177
Other bindings just import zmq.h. Did I miss any?
> Sorry for disappearing, baby and full time job is a lot :-), hopefully
> I'm back...
No worries, perfectly understandable :-)
> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi
> wrote:
> > Sorry, I meant if we go with (1), not (2), we might bump the size as
> > well, since we are already doing another ABI-breaking change.
> >
> > I agree on the solution as well.
> >
> > On Mon, 2016-08-29 at 17:12 +0200, Pieter Hintjens wrote:
> >> I'm confused between the (1) and (2) choices, and can't see where
> >> bumping the message size fits.
> >>
> >> Nonetheless, I think bumping the size, fixing the alignment issues,
> >> and bumping the ABI version is the best solution here.
> >>
> >> On Fri, Aug 26, 2016 at 12:33 PM, Luca Boccassi
> >> wrote:
> >> > I've given some more thoughts and testing to the alignment issue. I can
> >> > reproduce the problem by enabling alignment checks on x86 too.
> >> >
> >> > But most importantly, I think we cannot get away from bumping the ABI
> >> > with this fix, however we rearrange it, simply because applications need
> >> > to be rebuilt against the new header to be fixed. A simple rebuild of
> >> > the libzmq.so is not enough. And the way to do this is to bump the ABI
> >> > so that distros can schedule transitions and rebuilds and so on.
> >> >
> >> > So the choice list is now restricted to:
> >> >
> >> > 1) Bump ABI
> >> > 2) Revert the fix and leave everything broken on sparc64 and some
> >> > aarch64 (rpi3 seems not to be affected, must depend on the SoC flavour)
> >> >
> >> > If we go with 2, we might as well get 2 birds with one stone and bump
> >> > the zmq_msg_t size to 128 as we have talked about in the past.
> >> >
> >> > Doron, this would help with the new UDP based socket types right?
> >> >
> >> > Pros of bumping msg size:
> >> >
> >> > - we can get rid of the malloc() in the lmsg type case as all the data
> >> > will fit
> >> >
> >> > Cons:
> >> >
> >> > - for the vsm/cmsg type cases (for most architectures anyway) it won't
> >> > fit anymore into a single cacheline
> >> >
> >> > Given all this, I'd say we should go for it.
> >> >
> >> > Opinions?
> >> >
> >> > On Sat, 2016-08-13 at 16:59 +0100, Luca Boccassi wrote:
> >> >> Hello,
> >> >>
> >> >> Trying to give some thoughts again on the libzmq 4.2 release. It's
> >> >> really long overdue!
> >> >>
> >> >> The main issue from my point of view is this change:
> >> >>
> >> >> https://github.com/zeromq/libzmq/commit/d9fb1d36ff2008966af538f722a1f4ab158dbf64
> >> >>
> >> >> -typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
> >> >> +/* union here ensures correct alignment on architectures that require
> >> >> it, e.g.
> >> >> + * SPARC
> >> >> + */
> >> >> +typedef union zmq_msg_t {unsigned char _ [64]; void *p; } zmq_msg_t;
> >> >>
> >> >>
> >> >> This is flagged by the common ABI checkers tools as an ABI breakage
> >> >> (see: http://abi-laboratory.pro/tracker/timeline/zeromq/ ). And it makes
> >> >> sense from this point of view: if some applications on some
> >> >> architectures are broken due to wrong alignment, they would need to be
> >> >> rebuilt, and the way to ensure that is to bump the ABI "current" digit
> >> >> to make sure maintainers do a rebuild.
> >> >>
> >> >> On the other hand, signaling an ABI breakage is a pain, and a cause of
> >> >> major churn for packagers and maintainers. It means for example a new
> >> >> package has to be created (eg: libzmq5 -> libzmq6), and a transition has
> >> >> to be started and all reverse dependencies need to be rebuilt. And if
> >> >> this is pointless for all save a few corner cases (eg SPARC64 as for
> >> >> above) it's all quite frustrating.
> >> >>
> >> >> So we have a choice to make before we release 4.2, four possibilities as
> >> >> far as I can see:
> >> >>
> >> >> 1) Ignore the ABI checkers and get yelled at by maintainers and
> >> >> packagers. Also the SPARC64 users will most likely NOT get their bug
> >> >> fixed
> >> >> 2) Bump ABI revision to 6 and get yelled at by maintainers and