[zeromq-dev] pyzmq -> pyczmq rewrite

Brian Knox briank at talksum.com
Mon Nov 18 12:10:28 CET 2013


Hey neat - I hadn't really noticed pyczmq before!  If you don't mind, I'd
like to fork it this week just to play with adding support for the zproxy
class I added to czmq (it's not in a stable release yet).  I haven't played
with CFFI before and would enjoy the opportunity to play with it and bother
folks with questions.  :)

Brian


On Mon, Nov 18, 2013 at 3:16 AM, Michael Haberler <mail17 at mah.priv.at>wrote:

> Hi Michel,
>
> Am 18.11.2013 um 04:52 schrieb Michel Pelletier <
> pelletier.michel at gmail.com>:
>
> > 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?
>
> well, it was all in place anyway - it turns out that using zframe.data(f)
> is sufficient because this supports enough of the buffer protocol to work:
>
>  f = zframe.recv(socket)
>  self.rx.ParseFromString(zframe.data(f))
>
> the sending side just becomes:
>
>  zframe.send(zframe.new(self.tx.SerializeToString()), socket, 0)
>
> ---
>
> re keyboard interrupt: I solved this by testing for
>  zpoller.terminated(poller) in the inner loop which I prefer anyway since
> it's synchronous delivery.
>
>
>
> I think what warrants some thought longer term: if errors from pyczmq
> calls should raise exceptions or not. It's a very C-ish interface which
> requires a lot of asserts around calls.
>
>
> - Michael
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131118/677d5959/attachment.html>


More information about the zeromq-dev mailing list