On 11/05/2011 09:09 PM, MinRK wrote:
>
> I'm now running into this assert rather a lot, when running the pyzmq
> test suite against current libzmq-master
>
> Assertion failed: msg_->flags () & msg_t::more (rep.cpp:75)
>
> All the test involves is a few ping/pong messages with req/rep pairs.
>
> I h
Hi,
Thanks for all the work.
I'm now running into this assert rather a lot, when running the pyzmq test
suite against current libzmq-master
Assertion failed: msg_->flags () & msg_t::more (rep.cpp:75)
All the test involves is a few ping/pong messages with req/rep pairs.
I haven't figured out a
i think i still do not understand.
flow control != monitoring
i think this is yet another manifestation of the old confusion between
routing and job scheduling. the issue is how much work it takes to deal with
a message. when this is large (say many seconds), then the simplest (and near
optimal)
Yes, this is C#. The poll event is going to tell you when data is
available, that's when you're going to do your recv.
--
Paul Betts
On Sat, Nov 5, 2011 at 4:54 PM, wrote:
> Hi Paul,
> Thanks for this suggestion. In the piece of code you just outline, I
> noticed there's no recv() method
Hi Paul,
Thanks for this suggestion. In the piece of code you just outline, I
noticed there's no recv() method been called, is the message still going to
come in? Also I just wanted to confirm that this is a C# code because that's
the only important thing to me right now. Also I'm not buildi
This exists in clrzmq as well, here's the gist of it:
Context ctx;
Socket socketForCtx;
PollItems[] pollItems;
pollItems[0] = socketForCtx.CreatePollItem(IOMultiPlex.POLLIN |
IOMultiPlex.POLLOUT);
pollItems[0].PollInHandler += (s, r) => Console.WriteLine("In!");
pollItems[0].PollInHandler += (s,
>From bb66f3cc3bc2a76d10f16e1206f35480eb250a07 Mon Sep 17 00:00:00 2001
From: Martin Sustrik
Date: Sat, 5 Nov 2011 16:05:18 +0100
Subject: [PATCH] Bug in trie fixed (issue 277)
When there were both '0' and '255' subnodes in (mtrie)
the removal of the node resulted in an infinite loop.
Fixed.
Si
On Sat, Nov 5, 2011 at 1:32 PM, Martin Sustrik wrote:
> If you have any concrete improvement in mind, feel free to propose it.
There are a set of things we wanted to add to the protocol, such as
socket type checking.
-Pieter
___
zeromq-dev mailing lis
On 11/05/2011 12:05 PM, Pieter Hintjens wrote:
> Perhaps we can talk about how to extend the wire protocol safely to
> allow new features to be added without breaking existing applications?
If you have any concrete improvement in mind, feel free to propose it.
Martin
On Sat, Nov 5, 2011 at 11:17 AM, lanre lawal wrote:
So I was wondering is there a way not to set the NOBLOCK
> option and then set a timeout (milliseconds) for the request so that it
> sticks around for data just for a specified period of time. That way I don't
> need to set the NOBLOCK option an
Hi Guys,
I have worked with the ZMQ library for over 4weeks now using it to receive
data from a remote address. I first worked with the PHP binding and everything
seemed to go fine. Now when I wanted to switch to ASP.NET, I got the clr-zmq
and was using it. However the problem with the clr-z
On Sat, Nov 5, 2011 at 11:21 AM, Martin Sustrik wrote:
> 2. The wire protocol for request/reply pattern was reverted to match the
> protocol used in 0MQ/2.1. (The publish/subscribe protocol remained
> unchanged though, providing the subscription forwarding feature.)
This is really good news. We
Hi all,
As discussed on this list last week, I've made following changes to 0MQ
trunk repository (libzmq):
1. Removed all the experimental functionality: Labels, commands,
new-style generic ROUTER socket, VTCP transport etc.
2. The wire protocol for request/reply pattern was reverted to match
13 matches
Mail list logo
