[zeromq-dev] Failing to synchronize 0mq sockets

Daniele Varrazzo daniele.varrazzo at gmail.com
Tue Apr 3 13:16:19 CEST 2012

On Tue, Apr 3, 2012 at 7:36 AM, Michel Pelletier
<pelletier.michel at gmail.com> wrote:
> Your example works fine for me if you change the tcp PUB endpoint
> transport to inproc.

This means that it doesn't work, does it? I mean, my program
establishes an unequivocal temporal sequence, that somehow is not
respected. I wonder why, as it makes syncing impossible even with the
best intentions. If it works using inproc and not other transports I
assume it only does by implementation accident.

If the example is correct, my question is *why* it doesn't work. What
is that breaks the sequentiality?

> I'm not sure what's going on, but the guide mentions only sharing
> contexts between threads with inproc transports. I think bind is
> synchronous but connect isn't, so perhaps your threads are
> synchronizing faster than connect can connect to the pub socket over
> tcp, and the sub socket is therefore missing a bunch of messages.

More or less this is the same conclusion I've reached: that connect()
doesn't block and returns before really establishing a connection. But
in this case how can you write a correct program using zmq? Is this a
design decision or an unexpected behaviour?

/me on the manual...

    a successful invocation of zmq_connect() does not indicate
    that a physical connection was or can actually be established.

Oh. I see. But at this point, what is the validity of the several
guide chapters I've been reading in in the last days? ("Signaling
between Threads", "Node Coordination"...).How does one writes a
correct program with concurrent workers synchronizing and
communicating via zmq? Is one forced to use the same communication
channel for synchronization and data (haven't rewired my brain yet to
figure out how)?

> Personally I would recommend to you using a multiprocess approach

I mostly share your view about the approach to concurrency in Python.
I am studying zmq exactly in the view of eventlet integration (which
is not as straightforward as I'd have expected: you can't use the
poller, apparently you can't use devices...). The attached example is
a simplified one, after I've taken away the layers of magic that could
have go wrong in the first place, and "maybe eventlet is breaking
something" is just one of the "threads" I've followed to try to
understand why the test program doesn't work.

Thank you for the attention.

-- Daniele

More information about the zeromq-dev mailing list