The API is going to be very similar, yes. Any differences will be minor.
On Sun, Feb 22, 2015 at 7:44 AM, Utsav Drolia utsavdro...@gmail.com wrote:
Would the API be the same for both projects? That way I can start with pyre
and move to python bindings for zyre when they mature.
On Feb 21,
Zyre has (since about a day) Python bindings via the zproject
generator that Zyre uses. I'm not sure they are 100% complete yet. See
latest commits to zproject. Pyre is an interesting alternative.
On Sat, Feb 21, 2015 at 11:26 PM, Utsav Drolia utsavdro...@gmail.com wrote:
Hi,
There is a project
Hi,
There is a project - pyre (https://github.com/zeromq/pyre) which is a python
implementation of the ZRE protocol.
Will zyre directly support python bindings or should one use pyre instead?
Thanks!
Utsav
___
zeromq-dev mailing list
Would the API be the same for both projects? That way I can start with pyre
and move to python bindings for zyre when they mature.
On Feb 21, 2015 7:15 PM, Pieter Hintjens p...@imatix.com wrote:
Zyre has (since about a day) Python bindings via the zproject
generator that Zyre uses. I'm not sure
It looks like the recently added code for supporting thread safe sockets
does not support returning the signalling FD for a socket that is marked
thread safe. How would these socket types be used in a polling reactor
then?
___
zeromq-dev mailing list
Specifically, something like epoll or kqueues?
On Sat, Feb 21, 2015 at 9:27 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
It looks like the recently added code for supporting thread safe sockets
does not support returning the signalling FD for a socket that is marked
thread safe. How would
Currently the thread safe sockets doesn't support polling on multiple
sockets as stated in the PR:
https://github.com/zeromq/libzmq/pull/1349
I'm planning to solve that by epoll like API where you create a poll and
then add sockets to it. The poll type will create a file descriptor that
will be
You will be able to create a signaler which is a file descriptor, associate
it with the socket and add it to the epoll or kqueue
On Sat, Feb 21, 2015 at 5:32 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Specifically, something like epoll or kqueues?
On Sat, Feb 21, 2015 at 9:27 AM, Thomas
I will hold off until you've fleshed out those details, but it sounds like
the API for getting the signaling FD will be different from what everything
else uses currently, which means there will be a class of socket types that
I will need to special case to support in my bindings. Is there anyway
s/comdition/condition/
On Sat, Feb 21, 2015 at 10:45 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Which all brings us to my next question -
Can we just move on to -std=c++11 for future libzmq versions? The big 3
compilers (well mostly, Microsoft still presents a few issues) support
C++11
Destroying a socket is still not thread safe, so the user still need to
synchronize that
On Feb 21, 2015 6:36 PM, Bjorn Reese bre...@mail1.stofanet.dk wrote:
On 02/21/2015 04:44 PM, Doron Somech wrote:
(https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have
I had a quick
On Sat, Feb 21, 2015 at 5:45 PM, Thomas Rodgers rodg...@twrodgers.com wrote:
Can we just move on to -std=c++11 for future libzmq versions? The big 3
compilers (well mostly, Microsoft still presents a few issues) support C++11
at this point.
I'd guess Yes, though it's worth asking the list.
The one need to dispose it. My plan was to support zmq_poll by create
signaler on each call.
On Feb 21, 2015 6:21 PM, Thomas Rodgers rodg...@twrodgers.com wrote:
I will hold off until you've fleshed out those details, but it sounds like
the API for getting the signaling FD will be different
On 02/21/2015 04:44 PM, Doron Somech wrote:
(https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have
I had a quick look at this class...
The workaround in the destructor is not thread-safe. Another thread
may enter and wait between the sync-unlock() and the end of the
Which all brings us to my next question -
Can we just move on to -std=c++11 for future libzmq versions? The big 3
compilers (well mostly, Microsoft still presents a few issues) support
C++11 at this point.
Many of the issues below would just 'go away' with the use of std::mutex,
in addition to not being exception safe, all of the explicit entry and
early exit from the mutex is a fully loaded footgun for some future
developer working on this code. RAII is a core idiom of C++ and scoped
locks/guards are the only sensible and safe way to write this sort of code
so that will
Hi all,
Be careful with requiring C++11 constructs. Some environments may need to
use older compilers. For example, building PyZMQ from source for Python
2.7 (and some early Python 3 releases) requires building with VS2008, which
does not support C++11.
Cheers,
André
On Sat, Feb 21, 2015 at
Why would these be not compile-able with newer versions of VC (I believe
VS2008 Goes EOL in July of this year)?
Note, changing the libzmq to build with -std=c++11 would not change the C89
compatibility of it's public API.
On Saturday, February 21, 2015, André Caron andre.l.ca...@gmail.com wrote:
You are right. I will change it to use scoped lock.
On Sat, Feb 21, 2015 at 6:36 PM, Bjorn Reese bre...@mail1.stofanet.dk
wrote:
On 02/21/2015 04:44 PM, Doron Somech wrote:
(https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have
I had a quick look at this class...
The
19 matches
Mail list logo
