Hi Kiu,
That was just a copy paste error in mail. I do have poll_items[1] initialized.
Do you see any issue why zmq_poll API just returns only the first message
received on each socket.
Thanks
Badhri
Sent from my iPhone
On Aug 18, 2014, at 5:31 PM, KIU Shueng Chuan wrote:
> Your snippet neit
... then, having realizing that it linked against the Ubuntu installed
default version (libzmq3), I re-ran this against libzmq4 and the current
libzmq 'trunk'. I get no races/issues in libzmq3 or libzmq4, but 4.1
definitely seems to have a problem, in that this test program is triggering
GCC's sta
H, I just ran this on my *nix box (Ubuntu 14.04, gcc4.8) with helgrind
and I get no races in zmq::msg_t::close() reported, nor do I see anything
in the implementation of zmq::msg_t::close() that's likely racey in
practice.
On Monday, August 18, 2014, Michi Henning wrote:
> Hi Thomas,
>
> tha
Your snippet neither initializes nor checks poll_items[1]. But no, revents
field doesn't need to be reset (nor initialized).
On Tue, Aug 19, 2014 at 8:14 AM, Badhrinath Manoharan
wrote:
> Hi,
>
> I have the following topology
>
> Client ---> Broker > Server
>
> Both the client and server ar
Hi,
I have the following topology
Client ---> Broker > Server
Both the client and server are sockets of type ZMQ_REQ while the Broker has
a socket connected to client and another Socket Connected to Server both
are of type ZMQ_BROKER.
void *frontend = zmq_socket (context, ZMQ_ROUTER);
Hi Thomas,
thanks for the quick answer!
> If the message size exceeds the 'vsm' message length limit, it becomes an
> 'lmsg'. This type is indeed heap allocated, and when the enclosing message
> type is copied, the copies share the reference to the underlying heap
> allocation (and any potent
If the message size exceeds the 'vsm' message length limit, it becomes an
'lmsg'. This type is indeed heap allocated, and when the enclosing message
type is copied, the copies share the reference to the underlying heap
allocation (and any potential data races that come along with that). The
lifet
On Fri, Aug 15, 2014 at 01:22:53PM +0300, artemv.zmq wrote:
> hi Goswin
>
> You mentioned:
>
> >With a level trigger you can poll() and then consume one message from
> >every socket that has input available. Rince and repeat. No socket can
> >starve any other.
>
> Why polling every time and do 1
On Fri, Aug 01, 2014 at 11:23:24AM -0700, Dave Peacock wrote:
> Have just run into this same issue. I haven't tried uclibc yet, tho thanks
> for that suggestion, will investigate later. For those of you running
> embedded linux or similar, under posix it looks like there are a few
> options for con
On Sun, Aug 17, 2014 at 10:22 PM, Merijn Verstraaten
wrote:
> Right, so the binary format is uint32_t/uint64_t, but with the restriction
> that the maximum value they should contain is INT32_MAX/INT64_MAX.
Yes. I guess this should be stated explicitly.
> And a, hopefully, last one: The ZAP RFC
I'm trying to devise a strategy how to deal with DEALER authentication with
PLAIN and CURVE auth, assuming a public network scenario (PLAIN would be
applicable if the public hop is encrypted for instance over a SSL websocket).
I have dealer clients, some of which do only getter ops; some do gett
11 matches
Mail list logo
