OK, I add a test for this condition, find a bug in my previous code
and fix this. Nothing better than a test to check your work :)
Here the new patch.
Fabien
2011/6/11 Martin Sustrik :
> On 06/11/2011 05:59 PM, Fabien Niñoles wrote:
>>
>> Here the new patch. I wasn't able however to make the t
Hi Steven,
> I'm looking at Windows named pipe support with IOCP and have most
> implemented but it appears it would be better to investigate turning
> around core component before bolting things above.
>
> The current /zmq_engine_t /implementation is as a reactor, an incoming
> event will retriev
I'm looking at Windows named pipe support with IOCP and have most
implemented but it appears it would be better to investigate turning around
core component before bolting things above.
The current *zmq_engine_t *implementation is as a reactor, an incoming event
will retrieve a buffer then populat
Hi all,
This patch provides first try on publisher side filtering. It is also
available in bidi-pipes branch.
I don't have much free time to work on it, so it would be helpful if
those interested in the feature grabbed the bidi-pipes branch, tested it
and reported or even patched any problem
Interesting read,
*DCTCP is an enhancement to the TCP congestion control algorithm for data
> center networks. It leverages Explicit Congestion Notification (ECN), a
> feature which is increasingly becoming available in modern data center
> switches. DCTCP sources extract multi-bit feedback on con
On 06/11/2011 05:59 PM, Fabien Niñoles wrote:
> Here the new patch. I wasn't able however to make the test fail
> without the fix. If you can figure out a way to achieve this, your
> welcome.
That looks better :)
As for the test case do it this way:
1. bind a SUB socket
2. start receiving with
Here the new patch. I wasn't able however to make the test fail
without the fix. If you can figure out a way to achieve this, your
welcome.
Fabien
2011/6/11 Fabien Niñoles :
> You mean, if xrecv/xsend return EAGAIN ? I can't see how could this
> happen with process_command returning 0, but you
On 11 juin 2011, at 17:05, Luc Heinrich wrote:
> * This is using ZMQ 2.1.7.
Sorry, I forgot to mention:
* This was tested on OS X 1.6.7.
--
Luc Heinrich - l...@honk-honk.com
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq
Hello,
This is a response to a request made in another thread [1] for a test case
allowing to reproduce the "Assertion failed: nbytes == sizeof (command_t)"
error on orderly shutdown. I should obviously have replied to the request
directly but I only recently joined the list and I don't have th
On 06/11/2011 04:24 PM, Fabien Niñoles wrote:
> You mean, if xrecv/xsend return EAGAIN ? I can't see how could this
> happen with process_command returning 0, but you're probably right, I
> will check it.
What can happen is that new commands arrive, they are processed, but the
processing doesn't
You mean, if xrecv/xsend return EAGAIN ? I can't see how could this
happen with process_command returning 0, but you're probably right, I
will check it.
Fabien
2011/6/11 Martin Sustrik :
> Hi Fabien,
>
>> And another update where I removed the block parameter;
>
> I've checked the patch.
>
> Ple
On 06/11/2011 02:15 PM, Pieter Hintjens wrote:
> Do we have figures for the cost of zmq_poll? I'm kind of sceptical of
> any optimization that's not based on solid numbers.
No figures, sorry. The actual advantage of epoll over poll/select should
show up only in setups with thousands of items in
Hi Fabien,
> And another update where I removed the block parameter;
I've checked the patch.
Please, have a look at socket_base_t::send and socket_base_t::recv
functions. There's process_commands() called in the loop. If the loop
iterates several times, it may happen that actual timeout will b
On Sat, Jun 11, 2011 at 1:59 PM, Martin Sustrik wrote:
> Ok. I should have not mentioned the second caveat. The real point is that
> epoll is meant to reduce complexity of polling from O(n) -- where n is the
> size of pollset -- to O(1). If we use epoll to implement zmq_poll(), we get
> complexit
On 11 June 2011 13:59, Martin Sustrik wrote:
> On 06/11/2011 11:23 AM, Pieter Hintjens wrote:
> > For the CZMQ zloop reactor, at least, we're only rebuilding the pollset
> > when there's a change. So that'd work nicely with epoll et al.
>
> Ok. I should have not mentioned the second caveat. The r
On 06/11/2011 11:23 AM, Pieter Hintjens wrote:
> For the CZMQ zloop reactor, at least, we're only rebuilding the pollset
> when there's a change. So that'd work nicely with epoll et al.
Ok. I should have not mentioned the second caveat. The real point is
that epoll is meant to reduce complexity o
For the CZMQ zloop reactor, at least, we're only rebuilding the pollset when
there's a change. So that'd work nicely with epoll et al.
-Pieter
On 11 Jun 2011 10:02, "Martin Sustrik" wrote:
> On 06/11/2011 12:04 AM, Marko Mikulicic wrote:
>
>> Just a comment: The performance gain with epoll et al.
On 06/11/2011 12:04 AM, Marko Mikulicic wrote:
> Just a comment: The performance gain with epoll et al. is tied to
> different API (only the file descriptors that are actually changed are
> passed to and from the API). Thus implementing old-style API like
> zmq_poll() on top of epo
18 matches
Mail list logo
