[zeromq-dev] client/server sockets -- stability
WallSt Prog
wallstprog at gmail.com
Wed Oct 18 15:32:05 CEST 2017
Thanks Luca! That's good to know.
On Mon, Oct 16, 2017 at 7:08 PM, Luca Boccassi <luca.boccassi at gmail.com>
wrote:
> On Mon, 2017-10-16 at 14:31 -0400, Bill Torpey wrote:
> > Thanks Luca!
> >
> > From the thread it sounds like the consensus is that you can have
> > thread-safe or multi-part, but not both, and that client/server
> > sockets will be in addition to router/dealer sockets, which will not
> > be deprecated going forward. Is that correct?
> >
> > If that’s the case, is it safe to assume that (a) client/server
> > socket types will continue to be supported going forward, and (b) the
> > essential property (block on mute) will remain the same?
> >
> > Regards,
> >
> > Bill
>
> It is going to be supported, yes absolutely - the API might change
> until it's declared stable, the behaviour too, although it is very very
> unlikely that a fundamental property like block on mute would be
> changed at this point.
>
> > > On Oct 16, 2017, at 2:00 PM, Luca Boccassi <luca.boccassi at gmail.com
> > > > wrote:
> > >
> > > On Mon, 2017-10-16 at 11:53 -0400, Bill Torpey wrote:
> > > > Hi All:
> > > >
> > > > Without going into too much detail (I’ll save that for another
> > > > post
> > > > when I’ve gotten all my ducks in a row), it looks like I’ve found
> > > > a
> > > > solution to the problems I’ve been having using different socket
> > > > types to do inter-thread synchronization, which ends up being
> > > > client/server sockets over inproc. (Which ironically has nothing
> > > > to
> > > > do with their thread-safety, but everything to do with the fact
> > > > that
> > > > sends will block until the message can be queued/delivered).
> > > >
> > > > I notice the disclaimer that these are drafts and subject to
> > > > change,
> > > > etc., so my question is whether there is any expectation around
> > > > when
> > > > these socket types will be declared “stable”?
> > > >
> > > > Can anyone shed any light on the process needed to move these to
> > > > stable status, and/or what the timeframe might be?
> > > >
> > > > Many thanks in advance for any help!
> > > >
> > > > Regards,
> > > >
> > > > Bill Torpey
> > >
> > > Documentation is missing, and also there was still recently some
> > > brainstorming on how to do something akin to multipart in the new
> > > sockets, which might require API breakages:
> > >
> > > https://github.com/zeromq/libzmq/issues/2699
> > >
> > > --
> > > Kind regards,
> > > Luca Boccassi_______________________________________________
> > > zeromq-dev mailing list
> > > zeromq-dev at lists.zeromq.org
> > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> --
> Kind regards,
> Luca Boccassi
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20171018/584c7568/attachment.htm>
More information about the zeromq-dev
mailing list