Final status update (hopefully!), CZMQ 4.0.1 is now out: https://github.com/zeromq/czmq/releases/tag/v4.0.1
Apologies for the troubles with the draft system, it should be now all right. On Tue, 2016-11-08 at 17:33 +0000, Luca Boccassi wrote: > Further status update: > > I found out that the implementation of the DRAFT APIs build mechanism in > zproject/czmq had a bug, and the DRAFT symbols were leaked as global in > the shared library even when DRAFT APIs are disabled (note that libzmq > is fine due to the differences between C and C++). > > I fixed this now for *nix (help from Windows MS VC++ experts would be > appreciated!): > > https://github.com/zeromq/czmq/pull/1549/files > https://github.com/zeromq/czmq/pull/1550/files > > I consider this bad enough to warrant a bugfix release, before it causes > troubles for distributions. I patched it manually in Debian before > kicking off the transition libczmq3 -> libczmq4. > > If there are no objections I intend to push CZMQ 4.0.1 tomorrow. Then we > can breath for a while :-) > > On Sat, 2016-11-05 at 07:44 +0000, Luca Boccassi wrote: > > Final status update: > > > > CZMQ 4.0.0 is out, announcement has been sent: > > > > https://github.com/zeromq/czmq/releases/tag/v4.0.0 > > > > What a ride :-) > > > > libzmq 4.2.0 has been already uploaded to Debian (Thanks László for the > > very quick upload!), now I hope I can get CZMQ 4.0.0 up too by tomorrow. > > > > On Fri, 2016-11-04 at 13:35 +0000, Luca Boccassi wrote: > > > Status update: > > > > > > CZMQ release notes PR is open: > > > > > > https://github.com/zeromq/czmq/pull/1542 > > > > > > I will be travelling now until the evening (might have some time at > > > airport), so if you have anything to add please merge and send a new > > > PR :-) > > > I would like to release v4.0.0 tonight, so that I can (barely!) make it > > > for Debian 9 transition freeze. Phew! > > > > > > On Fri, 2016-11-04 at 10:46 +0000, Luca Boccassi wrote: > > > > Status update: > > > > > > > > libzmq 4.2.0 is out! Email sent to the announce list. > > > > > > > > https://github.com/zeromq/libzmq/releases/tag/v4.2.0 > > > > > > > > CZMQ is next! > > > > > > > > On Fri, 2016-11-04 at 09:52 +0000, Luca Boccassi wrote: > > > > > Status update: > > > > > > > > > > Added missing CTX option to CZMQ, retired more deprecated methods that > > > > > are in STABLE classes. > > > > > > > > > > Fixed a few typos in the rel notes (thanks Himikof and Paddor!), still > > > > > waiting for someone to merge: > > > > > > > > > > https://github.com/zeromq/libzmq/pull/2189 > > > > > > > > > > > > > > > On 3 November 2016 at 09:34, Luca Boccassi <luca.bocca...@gmail.com> > > > > > wrote: > > > > > > Status update: > > > > > > > > > > > > I've added all the missing options to CZMQ (check please!), and I > > > > > > prepared > > > > > > the release notes for libzmq 4.2, waiting for a merge: > > > > > > > > > > > > https://github.com/zeromq/libzmq/pull/2189 > > > > > > > > > > > > Anything else we should mention? > > > > > > > > > > > > > > > > > > On Nov 1, 2016 21:33, "Luca Boccassi" <luca.bocca...@gmail.com> > > > > > > wrote: > > > > > >> > > > > > >> Status update: > > > > > >> > > > > > >> libzmq 4.1.6, libzmq 4.2.0-rc1 and czmq 4.0.0-rc1 are out on > > > > > >> Github: > > > > > >> > > > > > >> https://github.com/zeromq/zeromq4-1/releases/tag/v4.1.6 > > > > > >> https://github.com/zeromq/libzmq/releases/tag/v4.2.0-rc1 > > > > > >> https://github.com/zeromq/czmq/releases/tag/v4.0.0-rc1 > > > > > >> > > > > > >> I'll send an email to the announce list shortly. As I wrote earlier > > > > > >> I'll work to have proper release notes for the stable releases. > > > > > >> > > > > > >> Unless there are any objections, I'm aiming to push libzmq 4.2.0 > > > > > >> stable tomorrow by the end of the day, and czmq the day after. > > > > > >> > > > > > >> It's an aggressive schedule, but I would _really_ like to get CZMQ > > > > > >> 4.0.0 in Debian and the transition freeze date is Saturday > > > > > >> (ABI/API is > > > > > >> borken so there needs to be a transition), and for that I need > > > > > >> libzmq > > > > > >> up before it. > > > > > >> > > > > > >> Any objections? > > > > > >> > > > > > >> I've also noticed that not all the libzmq socket options are > > > > > >> available > > > > > >> in CZMQ, so this gives me some time to fix that. > > > > > >> > > > > > >> > > > > > >> On 1 November 2016 at 14:48, Doron Somech <somdo...@gmail.com> > > > > > >> wrote: > > > > > >> > Great news! > > > > > >> > > > > > > >> > On Tue, Nov 1, 2016 at 4:07 PM, Luca Boccassi > > > > > >> > <luca.bocca...@gmail.com> > > > > > >> > wrote: > > > > > >> >> > > > > > >> >> Status update: > > > > > >> >> > > > > > >> >> - v2 APIs are gone from CZMQ: > > > > > >> >> https://github.com/zeromq/czmq/pull/1531 > > > > > >> >> https://github.com/zeromq/czmq/pull/1532 > > > > > >> >> - PR is out to bump the libtool version and changelog for > > > > > >> >> libzmq: > > > > > >> >> https://github.com/zeromq/libzmq/pull/2184 > > > > > >> >> - PR is out to backport the zmq_msg_t fix to 4.1: > > > > > >> >> https://github.com/zeromq/zeromq4-1/pull/155 > > > > > >> >> > > > > > >> >> Once it's all merged I will tag 4.2.0~rc1 first, then release > > > > > >> >> 4.1.6 > > > > > >> >> from > > > > > >> >> zeromq4-1 since quite a few fixes have accumulated. Then I'll > > > > > >> >> send PRs > > > > > >> >> to prepare for CZMQ 4.0.0~rc1. > > > > > >> >> > > > > > >> >> After the RCs are out, I'll work on the changelogs/NEWS files > > > > > >> >> (help is > > > > > >> >> appreciated!) as they have fallen dramatically behind. > > > > > >> >> > > > > > >> >> I'll also prepare more formal release notes for the stable > > > > > >> >> rels, the > > > > > >> >> RCs > > > > > >> >> will have just a quick note since they are RCs. > > > > > >> >> > > > > > >> >> On Mon, 2016-10-31 at 23:47 +0000, Luca Boccassi wrote: > > > > > >> >> > Cool! > > > > > >> >> > > > > > > >> >> > I can take care of it if you like. Tentative plan: > > > > > >> >> > > > > > > >> >> > Tomorrow push an RC1 for libzmq, then the pr to CZMQ to > > > > > >> >> > retire v2 > > > > > >> >> > APIs, > > > > > >> >> > then the RC1 for CZMQ. > > > > > >> >> > > > > > > >> >> > If it's all good then a couple days later the finals. I would > > > > > >> >> > really > > > > > >> >> > like > > > > > >> >> > to make it for the debian 9 transition freeze which is > > > > > >> >> > Saturday. > > > > > >> >> > > > > > > >> >> > On Oct 31, 2016 22:23, "Doron Somech" <somdo...@gmail.com> > > > > > >> >> > wrote: > > > > > >> >> > > > > > > >> >> > > Sorry, yes, lets do it :) > > > > > >> >> > > > > > > > >> >> > > On Oct 31, 2016 11:44 PM, "Luca Boccassi" > > > > > >> >> > > <luca.bocca...@gmail.com> > > > > > >> >> > > wrote: > > > > > >> >> > > > > > > > >> >> > >> Ping :-) > > > > > >> >> > >> > > > > > >> >> > >> On Oct 28, 2016 18:48, "Luca Boccassi" > > > > > >> >> > >> <luca.bocca...@gmail.com> > > > > > >> >> > >> wrote: > > > > > >> >> > >> > > > > > >> >> > >>> I have sent a solution for the alignment problem that > > > > > >> >> > >>> solves the > > > > > >> >> > >>> sigbus > > > > > >> >> > >>> problem without breaking ABI compat (plus follow-up for > > > > > >> >> > >>> VC++ - > > > > > >> >> > >>> sorry > > > > > >> >> > >>> Windows guys https://github.com/zeromq/libzmq/pull/2179 ). > > > > > >> >> > >>> > > > > > >> >> > >>> I tested the alignment and sigbus problem on x86_64 by > > > > > >> >> > >>> enabling > > > > > >> >> > >>> alignment check with: > > > > > >> >> > >>> > > > > > >> >> > >>> __asm__("pushf\norl $0x40000,(%rsp)\npopf"); > > > > > >> >> > >>> > > > > > >> >> > >>> All was fine. > > > > > >> >> > >>> > > > > > >> >> > >>> I ran tests built from the zeromq4-1 repository against a > > > > > >> >> > >>> shared > > > > > >> >> > >>> lib > > > > > >> >> > >>> from the head of libzmq repo, and they all run fine minus > > > > > >> >> > >>> the > > > > > >> >> > >>> ZMQ_REQ_CORRELATE one but that option was borken anyway. > > > > > >> >> > >>> > > > > > >> >> > >>> This allows us to do a release now, and then when we are > > > > > >> >> > >>> ready we > > > > > >> >> > >>> can do > > > > > >> >> > >>> the ABI breakage, without blocking 4.2. Which is nice > > > > > >> >> > >>> since it > > > > > >> >> > >>> means > > > > > >> >> > >>> it > > > > > >> >> > >>> might make it for Debian 9! > > > > > >> >> > >>> > > > > > >> >> > >>> So, Doron et al, shall we do the bump this weekend? > > > > > >> >> > >>> > > > > > >> >> > >>> On Thu, 2016-10-20 at 17:12 -0500, Thomas Rodgers wrote: > > > > > >> >> > >>> > I will have some time most likely the week of Nov6 (off > > > > > >> >> > >>> > for a > > > > > >> >> > >>> > week > > > > > >> >> > >>> > of > > > > > >> >> > >>> C++ > > > > > >> >> > >>> > Committee 'fun') to test different message size > > > > > >> >> > >>> > alternatives. > > > > > >> >> > >>> > I'll > > > > > >> >> > >>> follow > > > > > >> >> > >>> > up with my results here for consideration the next time > > > > > >> >> > >>> > we are > > > > > >> >> > >>> inclined to > > > > > >> >> > >>> > break the ABI compatibility :) > > > > > >> >> > >>> > > > > > > >> >> > >>> > On Sunday, October 16, 2016, Brian Knox > > > > > >> >> > >>> > <bk...@digitalocean.com> > > > > > >> >> > >>> wrote: > > > > > >> >> > >>> > > > > > > >> >> > >>> > > A new stable version would definitely help me in my > > > > > >> >> > >>> > > quest to > > > > > >> >> > >>> > > get > > > > > >> >> > >>> ZeroMQ > > > > > >> >> > >>> > > support enabled by default in rsyslog in distros. > > > > > >> >> > >>> > > > > > > > >> >> > >>> > > On Sun, Oct 16, 2016 at 2:40 PM Doron Somech > > > > > >> >> > >>> > > <somdo...@gmail.com> > > > > > >> >> > >>> wrote: > > > > > >> >> > >>> > > > > > > > >> >> > >>> > >> I say lets bump. > > > > > >> >> > >>> > >> > > > > > >> >> > >>> > >> On Oct 15, 2016 20:32, "Luca Boccassi" > > > > > >> >> > >>> > >> <luca.bocca...@gmail.com> > > > > > >> >> > >>> wrote: > > > > > >> >> > >>> > >> > > > > > >> >> > >>> > >>> As Thomas said, false sharing would be a real issue > > > > > >> >> > >>> > >>> with > > > > > >> >> > >>> > >>> 96. > > > > > >> >> > >>> > >>> > > > > > >> >> > >>> > >>> So given a release is long due, at this point I'd > > > > > >> >> > >>> > >>> say to > > > > > >> >> > >>> > >>> drop > > > > > >> >> > >>> > >>> this > > > > > >> >> > >>> for > > > > > >> >> > >>> > >>> the moment. > > > > > >> >> > >>> > >>> > > > > > >> >> > >>> > >>> What do we do for the change to union for > > > > > >> >> > >>> > >>> zmq_msg_t? Bump > > > > > >> >> > >>> > >>> ABI > > > > > >> >> > >>> version or > > > > > >> >> > >>> > >>> not? > > > > > >> >> > >>> > >>> > > > > > >> >> > >>> > >>> On Thu, 2016-10-06 at 09:53 +0300, Doron Somech > > > > > >> >> > >>> > >>> wrote: > > > > > >> >> > >>> > >>> > No new socket type, I worked at the time on binary > > > > > >> >> > >>> > >>> > message > > > > > >> >> > >>> > >>> > type, > > > > > >> >> > >>> might > > > > > >> >> > >>> > >>> > complete it sometime, but it is not urgent. > > > > > >> >> > >>> > >>> > > > > > > >> >> > >>> > >>> > If there is a lot of performance penalty we can > > > > > >> >> > >>> > >>> > give it > > > > > >> >> > >>> > >>> > up, > > > > > >> >> > >>> > >>> > I > > > > > >> >> > >>> will > > > > > >> >> > >>> > >>> > find another solution for the Radio-Dish. > > > > > >> >> > >>> > >>> > > > > > > >> >> > >>> > >>> > What about 96 bytes? same penalty? > > > > > >> >> > >>> > >>> > > > > > > >> >> > >>> > >>> > Regarding the binding, I'm not sure. > > > > > >> >> > >>> > >>> > > > > > > >> >> > >>> > >>> > On Sat, Oct 1, 2016 at 9:14 PM, Luca Boccassi < > > > > > >> >> > >>> luca.bocca...@gmail.com> > > > > > >> >> > >>> > >>> wrote: > > > > > >> >> > >>> > >>> > > 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#L > > > > > >> >> > >>> 177 > > > > > >> >> > >>> > >>> > > > > > > > >> >> > >>> > >>> > > 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 > > > > > >> >> > >>> > >>> > >> < > > > > > >> >> > >>> > >>> luca.bocca...@gmail.com> 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 < > > > > > >> >> > >>> > >>> luca.bocca...@gmail.com> 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/trac > > > > > >> >> > >>> ker/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 packagers > > > > > >> >> > >>> > >>> > >> >> >> 3) Revert the above change and postpone > > > > > >> >> > >>> > >>> > >> >> >> it to > > > > > >> >> > >>> > >>> > >> >> >> when > > > > > >> >> > >>> > >>> > >> >> >> we > > > > > >> >> > >>> have a > > > > > >> >> > >>> > >>> more > > > > > >> >> > >>> > >>> > >> >> >> generally useful reason to break ABI > > > > > >> >> > >>> > >>> > >> >> >> (bump > > > > > >> >> > >>> > >>> > >> >> >> zmq_msg_t > > > > > >> >> > >>> from 64 > > > > > >> >> > >>> > >>> to 128 > > > > > >> >> > >>> > >>> > >> >> >> bytes for example, Doron?) > > > > > >> >> > >>> > >>> > >> >> >> 4) Try to be clever and revert the above > > > > > >> >> > >>> > >>> > >> >> >> change > > > > > >> >> > >>> > >>> > >> >> >> and > > > > > >> >> > >>> > >>> > >> >> >> use > > > > > >> >> > >>> > >>> something like > > > > > >> >> > >>> > >>> > >> >> >> #pragma pack(8). This will fool the ABI > > > > > >> >> > >>> > >>> > >> >> >> checkers > > > > > >> >> > >>> > >>> > >> >> >> (I > > > > > >> >> > >>> tried > > > > > >> >> > >>> > >>> it), and given > > > > > >> >> > >>> > >>> > >> >> >> that typedef is only used externally to > > > > > >> >> > >>> > >>> > >> >> >> allocate > > > > > >> >> > >>> > >>> > >> >> >> the > > > > > >> >> > >>> right > > > > > >> >> > >>> > >>> size it > > > > > >> >> > >>> > >>> > >> >> >> shouldn't actually affect anything, > > > > > >> >> > >>> > >>> > >> >> >> apart from > > > > > >> >> > >>> > >>> > >> >> >> the > > > > > >> >> > >>> users of > > > > > >> >> > >>> > >>> SPARC64 > > > > > >> >> > >>> > >>> > >> >> >> which should get the bugfix with this > > > > > >> >> > >>> > >>> > >> >> >> too. This > > > > > >> >> > >>> > >>> > >> >> >> is > > > > > >> >> > >>> > >>> > >> >> >> very > > > > > >> >> > >>> > >>> sneaky :-) > > > > > >> >> > >>> > >>> > >> >> >> > > > > > >> >> > >>> > >>> > >> >> >> CC'ing Lazslo, the Debian maintainer, > > > > > >> >> > >>> > >>> > >> >> >> given what > > > > > >> >> > >>> > >>> > >> >> >> we > > > > > >> >> > >>> choose to > > > > > >> >> > >>> > >>> do might > > > > > >> >> > >>> > >>> > >> >> >> result in a lot of work for him :-) > > > > > >> >> > >>> > >>> > >> >> >> > > > > > >> >> > >>> > >>> > >> >> >> Opinions? > > > > > >> >> > >>> > >>> > >> >> >> > > > > > >> >> > >>> > >>> > >> >> >> Kind regards, > > > > > >> >> > >>> > >>> > >> >> >> Luca Boccassi > > > > > >> >> > >>> > >>> > >> >> >> > > > > > >> >> > >>> > >>> > >> >> >> On Tue, 2016-05-03 at 10:39 +0200, Pieter > > > > > >> >> > >>> > >>> > >> >> >> Hintjens > > > > > >> >> > >>> wrote: > > > > > >> >> > >>> > >>> > >> >> >> > Hi all, > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > I'm just throwing some ideas on the > > > > > >> >> > >>> > >>> > >> >> >> > table. We > > > > > >> >> > >>> > >>> > >> >> >> > have a > > > > > >> >> > >>> good > > > > > >> >> > >>> > >>> package of > > > > > >> >> > >>> > >>> > >> >> >> > work on master and it's probably time > > > > > >> >> > >>> > >>> > >> >> >> > to make > > > > > >> >> > >>> > >>> > >> >> >> > a > > > > > >> >> > >>> > >>> > >> >> >> > 4.2 > > > > > >> >> > >>> release. > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > Luca has already back-ported the > > > > > >> >> > >>> > >>> > >> >> >> > enable/disable > > > > > >> >> > >>> > >>> > >> >> >> > draft > > > > > >> >> > >>> > >>> design from > > > > > >> >> > >>> > >>> > >> >> >> > zproject (CZMQ et al). Yay! So we can > > > > > >> >> > >>> > >>> > >> >> >> > now > > > > > >> >> > >>> > >>> > >> >> >> > release > > > > > >> >> > >>> stable > > > > > >> >> > >>> > >>> master > > > > > >> >> > >>> > >>> > >> >> >> > safely, while continuing to refine and > > > > > >> >> > >>> > >>> > >> >> >> > extend > > > > > >> >> > >>> > >>> > >> >> >> > the > > > > > >> >> > >>> draft API > > > > > >> >> > >>> > >>> sections. > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > I propose: > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > - to end with the stable fork policy; > > > > > >> >> > >>> > >>> > >> >> >> > this was > > > > > >> >> > >>> > >>> > >> >> >> > needed > > > > > >> >> > >>> years > > > > > >> >> > >>> > >>> ago when > > > > > >> >> > >>> > >>> > >> >> >> > we had massively unstable masters. > > > > > >> >> > >>> > >>> > >> >> >> > It's no > > > > > >> >> > >>> > >>> > >> >> >> > longer > > > > > >> >> > >>> > >>> > >> >> >> > a > > > > > >> >> > >>> problem. > > > > > >> >> > >>> > >>> > >> >> >> > - to use the github release function > > > > > >> >> > >>> > >>> > >> >> >> > for > > > > > >> >> > >>> > >>> > >> >> >> > libzmq > > > > > >> >> > >>> releases > > > > > >> >> > >>> > >>> and deprecate > > > > > >> >> > >>> > >>> > >> >> >> > the separate delivery of tarballs. > > > > > >> >> > >>> > >>> > >> >> >> > - we aim to make a 4.2.0 rc asap, then > > > > > >> >> > >>> > >>> > >> >> >> > fix any > > > > > >> >> > >>> > >>> > >> >> >> > issues > > > > > >> >> > >>> we > > > > > >> >> > >>> > >>> get, with > > > > > >> >> > >>> > >>> > >> >> >> > patch releases as usual. > > > > > >> >> > >>> > >>> > >> >> >> > - we backport the release function to > > > > > >> >> > >>> > >>> > >> >> >> > older > > > > > >> >> > >>> > >>> > >> >> >> > maintained > > > > > >> >> > >>> > >>> releases (4.1, > > > > > >> >> > >>> > >>> > >> >> >> > 3.2) so that their tarballs are > > > > > >> >> > >>> > >>> > >> >> >> > provided by > > > > > >> >> > >>> > >>> > >> >> >> > github > > > > > >> >> > >>> instead > > > > > >> >> > >>> > >>> of > > > > > >> >> > >>> > >>> > >> >> >> > downloads.zeromq.org. > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > Problems: > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > - this will break a few things that > > > > > >> >> > >>> > >>> > >> >> >> > depend on > > > > > >> >> > >>> > >>> downloads.zeromq.org. To > > > > > >> >> > >>> > >>> > >> >> >> > be fixed as we go. > > > > > >> >> > >>> > >>> > >> >> >> > - github tarballs are not identical to > > > > > >> >> > >>> > >>> > >> >> >> > source > > > > > >> >> > >>> tarballs, > > > > > >> >> > >>> > >>> particularly > > > > > >> >> > >>> > >>> > >> >> >> > they lack `configure`. I propose > > > > > >> >> > >>> > >>> > >> >> >> > changing our > > > > > >> >> > >>> autotools > > > > > >> >> > >>> > >>> build > > > > > >> >> > >>> > >>> > >> >> >> > instructions so they always start with > > > > > >> >> > >>> > >>> > >> >> >> > `./autogen,sh` > > > > > >> >> > >>> no > > > > > >> >> > >>> > >>> matter where > > > > > >> >> > >>> > >>> > >> >> >> > the sources come from. > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > I think this will work and also let us > > > > > >> >> > >>> > >>> > >> >> >> > gracefully > > > > > >> >> > >>> > >>> deprecate/switch off > > > > > >> >> > >>> > >>> > >> >> >> > the downloads box. > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > -Pieter > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > _______________________________________________ > > > > > >> >> > >>> > >>> > >> >> >> > zeromq-dev mailing list > > > > > >> >> > >>> > >>> > >> >> >> > zeromq-dev@lists.zeromq.org > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > > > > > > >> >> > >>> > >>> > >> >> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > >> >> > >>> > >>> > >> >> >> > > > > > >> >> > >>> > >>> > >> >> >> > > > > > >> >> > >>> > >>> > >> >> > > > > > > >> >> > >>> > >>> > >> >> > > > > > > >> >> > >>> > >>> > >> >> > > > > > > >> >> > >>> > >>> > >> >> > _______________________________________________ > > > > > >> >> > >>> > >>> > >> >> > zeromq-dev mailing list > > > > > >> >> > >>> > >>> > >> >> > zeromq-dev@lists.zeromq.org > > > > > >> >> > >>> > >>> > >> >> > > > > > > >> >> > >>> > >>> > >> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > >> >> > >>> > >>> > >> >> _______________________________________________ > > > > > >> >> > >>> > >>> > >> >> zeromq-dev mailing list > > > > > >> >> > >>> > >>> > >> >> zeromq-dev@lists.zeromq.org > > > > > >> >> > >>> > >>> > >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > >> >> > >>> > >>> > >> > > > > > > >> >> > >>> > >>> > >> > > > > > > >> >> > >>> > >>> > > > > > > > >> >> > >>> > >>> > > > > > >> >> > >>> > >>> _______________________________________________ > > > > > >> >> > >>> > >> zeromq-dev mailing list > > > > > >> >> > >>> > >> zeromq-dev@lists.zeromq.org > > > > > >> >> > >>> > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > >> >> > >>> > > > > > > > >> >> > >>> > > > > > > > >> >> > >>> > _______________________________________________ > > > > > >> >> > >>> > zeromq-dev mailing list > > > > > >> >> > >>> > zeromq-dev@lists.zeromq.org > > > > > >> >> > >>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > >> >> > >>> > > > > > >> >> > >>> > > > > > >> >> > >>> > > > > > >> >> > > > > > >> >> > > > > > >> > > > > > > > > > > > > > > > > > > > > >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
