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. > 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. Also, either end of a zmq connection can bind and the other connect. Once established, the two endpoints are peers, it matters not which one was initially "binding" and the other "connecting" and to make that happen, connect needs to succeed without guarantee that the endpoint it is connecting to is bound yet. > 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. inproc and PAIR is fine for purely internal communication between threads, but that's not what your doing, you're trying to sync to what is essentially an external resource with an internal mechanism. > 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...). That's because eventlet has its own "event loop". There's no need for zmq.poll because eventlet is in charge of what happens when. I don't know much about eventlet, but it's likely you can tell it to "switch" threads on zmq events by passing the eventlet loop a file descriptor for a zmq socket. This is a pretty advanced pattern. Check out the gevent_zeromq integration in pypi for a great example of a very elegant way to integrate zeromq with an green thread system like eventlet. -Michel _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
