[zeromq-dev] pyzmq -> pyczmq rewrite
pelletier.michel at gmail.com
Mon Nov 18 04:52:16 CET 2013
On Sun, Nov 17, 2013 at 11:58 AM, Michael Haberler <mail17 at mah.priv.at>wrote:
> Hi Michel,
> just rewrote a protobuf/pyzmq Python application to use pyczmq (because
> I'm interested in beacon and securitiy support)
> first - no surprise; great job!
Awesome, and thanks! You could be pyczmq's first real-world user. :)
> just a note on the zframe wrapping:
> It would be handy to have a wrapping which supports the buffer call
> interface (such as strings, arrays, and buffers).
zframe.data() returns a cffi.buffer object, which is sort of a quasi-buffer
object. I don't know much about the rational behind it,but the cffi docs
point to some frustration reconciling the different buffer/Py_buf
interfaces between various python versions, which I gather is the rational
See this thread:
> f = zframe.recv(socket)
> m = buffer(zframe.data(f),0,zframe.size(f))
> r = Container() # my toplevel protobuf message
I don't know protobuf, but it seems like there should be a way for it to
work directly with cffi.buffer, or maybe cffi needs a little patch in that
regard (I've already half-forgotten the issue there, the thread above might
clear that up).
As way of example, I worked out this little bit of code that exercises the
"one less copy" operation in straight libzmq. This code depends on pyczmq,
This uses ctypes.Structure.from_buffer to copy objects to and from an
mmaped file with no serialization, in theory the only serializing happens
"out of process" by the kernel to and from the mapped file. Maybe some
ideas here might help?
> The other thing I noted is that handling of KeyboardInterrupt is different
> from pyzmq - which exits; pyczmq doesnt. Not necessarily a defect.
I'll look into that this week, thanks for your comments!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev