Hello.
I have been experimenting with zmq and now I realize that this zfl library is
exactly what I need. I'm trying to build classic database client-server
communication with zmq.
Here is what I have in my mind. I would appreciate any comments.
---
In my system one client must be tied and
In Mac OSX 10.6.6 zfl build fails. It worked few months ago.
git clone git://github.com/zeromq/zfl.git
cd zfl
sh autogen.sh
./configure
make all
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../include -Wall
-D_DARWIN_C_SOURCE -D_REENTRANT -D_THREAD_SAFE -std=c99 -DLINUX -Wno
Hi all,
There has been a lot updates to the clrzmq2 bindings recently and I
thought I'd announce some more highlights.
Some new devices added:
Forwarder
Streamer
AsyncReturn -> XREP <- PULL
Added socket object event handlers, these can then be passes to an
overload version of the static Contex
On 02/09/2011 04:21 PM, Pieter Hintjens wrote:
> On Wed, Feb 9, 2011 at 4:11 PM, Martin Sustrik wrote:
>
>> It introduces a special thread ("reaper thread") to handle socket
>> shutdown asynchronously. The patch should have following consequences:
>
> Does this also solve the problem of zmq_term d
On Wed, Feb 9, 2011 at 4:11 PM, Martin Sustrik wrote:
> It introduces a special thread ("reaper thread") to handle socket
> shutdown asynchronously. The patch should have following consequences:
Does this also solve the problem of zmq_term deadlocking when there
are sockets still open in the sam
Hi all,
I've just committed a rather extensive patch to the master.
It introduces a special thread ("reaper thread") to handle socket
shutdown asynchronously. The patch should have following consequences:
1. zmq_close() just passes the socket to the reaper thread and exits
immediately.
2. The
On Wed, Feb 9, 2011 at 4:53 AM, James Bardin wrote:
> Yes, it was just the amount of code, plus the zfl that confused me,
> and being slow in c, it seemed a little daunting.
I'll explain in more detail using some of the in progress docs which
describe two prototype designs (proto2, proto3). Warn
On Wed, Feb 9, 2011 at 7:54 AM, Martin Sustrik wrote:
> Yes, timeout and auto-resend of request in case of node failure are on
> the roadmap. However, nobody tried to implement that yet. Which is kind
> of interesting given it's pretty low hanging fruit (no synchronisation
> issues, no messy mult
