No objections here - been using czmq off various commits off head for over a year anyway ;)
On Tue, Nov 1, 2016 at 5:33 PM 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 > >> > >>> > >> > >>> > >> > >>> > >> > >> > > > _______________________________________________ > 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
