Martin Sustrik wrote: > Hi Min, > > >> zmq_device is particularly valuable in Python. Due to Python's infamous >> GIL, having >> a C-thread that will remain responsive regardless of blocking Python >> code (e.g. a FORWARDER device as heartbeat) >> is a pretty big deal. >> >> I imagine that when we bring pyzmq up to speed on 3.0, we will have to >> reimplement some amount of zmq_device >> in Cython to restore this extremely useful functionality. >> > > I think you misunderstood. The idea is to split devices into a separate > project, not to ditch them. > which did already happen for the standalone devices, a while back https://github.com/imatix/zdevices though this might be out of date (I'm not clear if libzapi or libzfl offers standalone device binaries, but certainly does offer a call to run devices from a config file)
It's worth remembering that the device binaries used fixed socket types thus queue was XREP and XREQ forwarder SUB PUB streamer was PUSH PULL on the contrary the 0MQ library call zmq_device pretty much allowed any socket types to be passed in which does allow for some interesting and innovative possibilities. but the point is an app using a device in the same address space calling zmq_device from a thread with an 'exotic' socket pairing ie (XREP XREP) in queue would not be able to be migrated to running the zmq_queue binary on a different machine as things currently stand. Jon _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
