On Fri, Dec 3, 2010 at 2:02 AM, Martin Sustrik wrote:
> Hi Dhammika,
>
>> Patch attached.
>
> I've checked the patch. Shouldn't the 'dispatch' be called when the engine
> is actually being moved to another thread (inside finalise_initialisation
> function) rather than in 'read' function?
>
New p
On 4 December 2010 00:46, Martin Sustrik wrote:
> On 12/03/2010 05:35 PM, Bob Beaty wrote:
> > Martin!
> > Thanks so very much. I hadn't looked into all the options for the
> > multicast and the ZMQ_RECOVERY_IVL is indeed the key.
> > Question: It's now in seconds. Is there any way to make it "te
Interesting the _ReadWriteBarrier() intrinsic does not work even though that
is what it is designed for. I manually add a memory fence using a locking
intrinsic or just disable optimisation of the entire function. For high
performance of TCP it is probably better to go with adding the intrinsic.
No,I didn't set socket ID .
On Mon, Dec 6, 2010 at 1:04 AM, Sven Koebnick wrote:
> did you set socket ID on both ends? req AND rep?
>
> ^5
> Sven
> -
> E = mc² ± 2dBA- everything is relative
>
did you
set socket ID on both ends? req AND rep?
^5
Sven
-
E = mc² ± 2dBA - everything is relative
-
-Original Message-
Date: Sat, 04 Dec 2010 13:59:45 +0100
Subject: [ze
Martin,
thanks, this is another partial draft patch submission and this time it
certainly looks a lot cleaner than last time.
Everything implemented in the XSUB/XPUB classes. the only difference between
SUB / XSUB seems to be that SUB implements
xsetsockopt and XSUB implements the functionality to
On 12/05/2010 10:37 AM, Troy Gutjahr wrote:
> OK, I tried to do this. Now when my REP client gets a timeout from
> zmq::poll when waiting for a response from the dead XREP server process,
> it tries to send another message to the same socket, which has a
> restarted XREP server process bound to the
OK, I tried to do this. Now when my REP client gets a timeout from
zmq::poll when waiting for a response from the dead XREP server process,
it tries to send another message to the same socket, which has a
restarted XREP server process bound to the other end. The send function
fails with errno = EFS
