On Tue, Apr 3, 2012 at 3:34 PM, Michel Pelletier <[email protected]> wrote: > On Tue, Apr 3, 2012 at 4:16 AM, Daniele Varrazzo > <[email protected]> wrote: >> On Tue, Apr 3, 2012 at 7:36 AM, Michel Pelletier >> <[email protected]> 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. > > It works, you just have to compare apples to apples. A tcp connect > can take several milliseconds, an inproc connect is essentially a > no-op. Your thread sync is not the performance critical part of your > program, why not just switch it to tcp, or switch the publisher to > inproc? What's the point of publishing externally but synchronizing > internally? If you use the same transports for pub and sync, and more > closely follow the synchronized subscriber pattern in the gude (using > REQ/REP, not PAIR) everything will work fine, and if you use a process > approach instead of threads you can scale beyond a core or two.
I've verified that using tcp req/rep synchronization works with my example. I agree that inproc sync makes no point if sockets are to talk across processes. But the example is about synchronization, it's just a toy to understand what can I build on. So, you say there is no guarantee that connections across different transports can be synced. Is there any guarantee that syncing solely on tcp *is* reliable? If zmq_connect can actually return before connecting, is the program now correct? (I've updated the script into <https://gist.github.com/2286899>) Or does it just work because of delays and still subject to chances? >> More or less this is the same conclusion I've reached: that connect() >> doesn't block and returns before really establishing a connection. > > Yep, it's asynchronous, that's a feature. Since you're using > eventlet, I imagine you can understand how that's a benefit to you in > the sense that it doesn't block your eventlet io loop. Well, I would have definitely preferred to have my thread (native or green) blocked until connection established: it would have made verifying the program correctness much easier. But I'm here just to learn a new paradigm, so I don't mind surprises here and there :) >> But >> in this case how can you write a correct program using zmq? Is this a >> design decision or an unexpected behaviour? > > It's exactly expected, your problem is synchronizing one transport > with another. Unify them an you will have no problems. This is was I was expecting across transports too, but now that I know it I'll stick to a single transport for synchronization. However, is it documented that syncing connections on the same transport does work? Because this now contradicts what the zmq_connect note says. Could it ever be that zmq will establish the connection on the req/rep pair while still delaying the pub/sub connection? Thank you, -- Daniele _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
