Re: [zeromq-dev] ZeroMQ C++ library freeze

[Thomas Rodgers]

Unsure then. If it was azmq I'd probably have more of an idea where to
look.

Do you have a minimal reporoducer case?

On Thu, May 27, 2021 at 8:10 AM Sierra Camargo, Jeisson Mauricio <
jeisson.sierra_cama...@siemens.com> wrote:

> Hello Tom thanks for your answer
>
>
>
> Im using the next c++ library: *libzmq-v140-mt-4_3_2*
>
>
>
>
>
> With best regards:
>
>
>
> Jeisson Mauricio Sierra Camargo
>
> Software Developer
>
> Siemens Mobility Colombia
>
> Mail: jeisson.sierra_cama...@siemens.com
>
> Phone: +573142050053
>
>
>
>
>
>
>
>
>
>
>
> *De:* zeromq-dev  *En nombre de *Thomas
> Rodgers
> *Enviado el:* miércoles, 26 de mayo de 2021 13:11
> *Para:* ZeroMQ development list 
> *CC:* Hernandez Navas, Michael Andres (SMO LAM RC-CO ITS SE) <
> michael_hernan...@siemens.com>; Sandoval Leon, Manuel Enrique (SMO LAM
> RC-CO ITS SE) 
> *Asunto:* Re: [zeromq-dev] ZeroMQ C++ library freeze
>
>
>
> There is more than one C++ library for ZeroMQ. Can you clarify which one
> you are referring to?
>
>
>
> Thanks,
>
> Tom.
>
>
>
> On Tue, May 25, 2021 at 11:35 PM Sierra Camargo, Jeisson Mauricio <
> jeisson.sierra_cama...@siemens.com> wrote:
>
> Hello
>
>
>
> I have a issue regarding library c++ ZeroMQ and a integration with a
> service as a suscriptor, in my source code, I connect to the publisher and
> I get all the information that it send me, in a variable time, the
> publisher freezing and stops sending me information, I activate some debugs
> but I don’t find whats happening, I use some options like keep alive
> without fix the issue
>
>
>
> Any opter option or comment regarding this issue?
>
>
>
> With best regards:
>
>
>
> Jeisson Mauricio Sierra Camargo
>
> Software Developer
>
> Siemens Mobility Colombia
>
> Mail: jeisson.sierra_cama...@siemens.com
>
> Phone: +573142050053
>
>
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.zeromq.org%2Fmailman%2Flistinfo%2Fzeromq-dev=04%7C01%7Cjeisson.sierra_camargo%40siemens.com%7Cb6c50927361745199bd808d9207e26b3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637576548932180123%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=ShjhyR80rY33JfgVdJTeD%2Fnow5N%2BB2KQouSapEXHOZs%3D=0>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ C++ library freeze

[Thomas Rodgers]

There is more than one C++ library for ZeroMQ. Can you clarify which one
you are referring to?

Thanks,
Tom.

On Tue, May 25, 2021 at 11:35 PM Sierra Camargo, Jeisson Mauricio <
jeisson.sierra_cama...@siemens.com> wrote:

> Hello
>
>
>
> I have a issue regarding library c++ ZeroMQ and a integration with a
> service as a suscriptor, in my source code, I connect to the publisher and
> I get all the information that it send me, in a variable time, the
> publisher freezing and stops sending me information, I activate some debugs
> but I don’t find whats happening, I use some options like keep alive
> without fix the issue
>
>
>
> Any opter option or comment regarding this issue?
>
>
>
> With best regards:
>
>
>
> Jeisson Mauricio Sierra Camargo
>
> Software Developer
>
> Siemens Mobility Colombia
>
> Mail: jeisson.sierra_cama...@siemens.com
>
> Phone: +573142050053
>
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZMQ - Send std::shared_ptr via inproc pub-sub?

[Thomas Rodgers]

Unless you positively acknowledge receipt there’s no completely reliable way to 
avoid this. In my case it was sufficient to periodically scan the table for 
‘uncollected’ refs and delete them. The receiving code still needs to be 
prepared for failure. 

> On Jun 24, 2020, at 1:53 PM, BJovke  wrote:
> 
> 
> That's a good solution.
> 
> But what happens if receiver never receives the message or doesn't take the 
> shared_ptr out of the table for some other reason?
> 
> It will be there forever.
> 
> Yes, you're right, sending a pointer to shared_ptr is not good because 
> message is sent asynchronously. It could be done by finding a way to know 
> that the message has been received.
> 
>> On Wed, Jun 24, 2020, 22:31 Thomas Rodgers  wrote:
>> 
>> 
>>>> On Jun 24, 2020, at 12:16 PM, Serguei Khasimkhanov  
>>>> wrote:
>>>> 
>>> 
>>> Thank you for the answers. I will reply to everyone in this email:
>>> 
>>> 
>>> > BJovke: You can send a pointer to your shared_ptr and then the receiver 
>>> > should copy construct (it's not an actual copy but a reference) it's own 
>>> > shared_ptr from it and forget about this pointer.
>>> 
>>> But the problem is that the original shared pointer may get destroyed or 
>>> replaced before the receiver can make a copy.
>>> 
>>> 
>>> > Rodrigo: If you can change the class definition, you could use the seldom 
>>> > seen std::enable_shared_from_this. 
>>> 
>>> If I send a pointer to the object, and the original shared_ptr to the 
>>> object goes out of scope, the object will be destroyed, and I won't be able 
>>> to `std::enable_shared_from_this`.
>>> 
>>> 
>>> > Sergei: You should serialize your object on publisher side -> send -> 
>>> > receive -> deserialize on subscriber. By object I mean target object on 
>>> > which shared_ptr points.
>>> 
>>> If I serialize a shared_ptr, it won't get copy-constructed, so the 
>>> reference count won't increase, and the owned pointer could get freed 
>>> before any receivers receive the message.
>>> 
>>> 
>>> > Rafal: Don't you think that sending a pointer to a memory is very error 
>>> > prone? e.g.: object may be destroyed before the receiver gets a 
>>> > serialized copy of shared_ptr as ref_count will not consider the fact 
>>> > that there is an instance of pointer in the ZMQ inproc buffer. IMO it 
>>> > would be better to send an object identifier which could be used by a 
>>> > receiver to retrieve data from some data provider.
>>> 
>>> Yes that's what I'm worried about. I don't know when to delete the pointer 
>>> because I don't know when everyone is done using it. That data provider 
>>> idea is my backup plan - if a receiver wants a copy of the data, they send 
>>> a separate data request to the publisher (through a separate socket), and 
>>> the publisher sends each one a properly-constructed copy of the 
>>> std::shared_ptr.
>>> 
>> 
>> I have code which has done this. As has been pointed out, this is tricky as 
>> you need to ensure the lifetime of the thing being pointed to until the 
>> receiver has received the message and taken ownership of the shared 
>> reference.
>> 
>> The way I ended up managing it was storing the shared_ptr in a table hashed 
>> by the pointer value (each hash bucket having it’s own mutex to reduce 
>> contention) and then sending the pointer value over the inproc socket as a 
>> key into the table. Retrieving the key then moves the shared_ptr out of the 
>> table so that the receiver has ownership of the shared_ptr ref.
>> 
>>> 
>>> > Bill: Your original question implies (but does not state explicitly) that 
>>> > you want to use 0mq to send shared_ptr’s to other threads in the same 
>>> > process.If that is the case you need to be cognizant of 
>>> > (https://en.cppreference.com/w/cpp/memory/shared_ptr):
>>> 
>>> Sorry for the confusion, yes it is all the same process. My goal is to have 
>>> each subscriber to copy-construct their own copy of the shared_ptr.
>>> 
>>> 
>>> > Harald: shared_pointers are thread safe  (not the underlying data). so 
>>> > you can copy the shared_ptr to the thread, read the date, and forget 
>>> > about it. no need to try some tricks like serialize pointer addresses, 
>>> > you will not succeed that way anyway.
>>>

Re: [zeromq-dev] ZMQ - Send std::shared_ptr via inproc pub-sub?

[Thomas Rodgers]

> On Jun 24, 2020, at 12:16 PM, Serguei Khasimkhanov  
> wrote:
> 
> 
> Thank you for the answers. I will reply to everyone in this email:
> 
> 
> > BJovke: You can send a pointer to your shared_ptr and then the receiver 
> > should copy construct (it's not an actual copy but a reference) it's own 
> > shared_ptr from it and forget about this pointer.
> 
> But the problem is that the original shared pointer may get destroyed or 
> replaced before the receiver can make a copy.
> 
> 
> > Rodrigo: If you can change the class definition, you could use the seldom 
> > seen std::enable_shared_from_this. 
> 
> If I send a pointer to the object, and the original shared_ptr to the object 
> goes out of scope, the object will be destroyed, and I won't be able to 
> `std::enable_shared_from_this`.
> 
> 
> > Sergei: You should serialize your object on publisher side -> send -> 
> > receive -> deserialize on subscriber. By object I mean target object on 
> > which shared_ptr points.
> 
> If I serialize a shared_ptr, it won't get copy-constructed, so the reference 
> count won't increase, and the owned pointer could get freed before any 
> receivers receive the message.
> 
> 
> > Rafal: Don't you think that sending a pointer to a memory is very error 
> > prone? e.g.: object may be destroyed before the receiver gets a serialized 
> > copy of shared_ptr as ref_count will not consider the fact that there is an 
> > instance of pointer in the ZMQ inproc buffer. IMO it would be better to 
> > send an object identifier which could be used by a receiver to retrieve 
> > data from some data provider.
> 
> Yes that's what I'm worried about. I don't know when to delete the pointer 
> because I don't know when everyone is done using it. That data provider idea 
> is my backup plan - if a receiver wants a copy of the data, they send a 
> separate data request to the publisher (through a separate socket), and the 
> publisher sends each one a properly-constructed copy of the std::shared_ptr.
> 

I have code which has done this. As has been pointed out, this is tricky as you 
need to ensure the lifetime of the thing being pointed to until the receiver 
has received the message and taken ownership of the shared reference.

The way I ended up managing it was storing the shared_ptr in a table hashed by 
the pointer value (each hash bucket having it’s own mutex to reduce contention) 
and then sending the pointer value over the inproc socket as a key into the 
table. Retrieving the key then moves the shared_ptr out of the table so that 
the receiver has ownership of the shared_ptr ref.

> 
> > Bill: Your original question implies (but does not state explicitly) that 
> > you want to use 0mq to send shared_ptr’s to other threads in the same 
> > process.If that is the case you need to be cognizant of 
> > (https://en.cppreference.com/w/cpp/memory/shared_ptr):
> 
> Sorry for the confusion, yes it is all the same process. My goal is to have 
> each subscriber to copy-construct their own copy of the shared_ptr.
> 
> 
> > Harald: shared_pointers are thread safe  (not the underlying data). so you 
> > can copy the shared_ptr to the thread, read the date, and forget about it. 
> > no need to try some tricks like serialize pointer addresses, you will not 
> > succeed that way anyway.
> 
> The problem is, I cannot just "copy the shared_ptr and forget about it". If 
> it goes out of scope before any subscribers make a copy, its data will be 
> deallocated.
> 
> 
> From: zeromq-dev  on behalf of Harald 
> Achitz 
> Sent: June 24, 2020 2:36 PM
> To: ZeroMQ development list 
> Subject: Re: [zeromq-dev] ZMQ - Send std::shared_ptr via inproc pub-sub?
>  
> shared_pointers are thread safe  (not the underlying data) 
> so you can copy the shared_ptr to the thread, read the date, and forget about 
> it
> no need to try some tricks like serialize pointer addresses, you will not 
> succeed that way anyway
> 
>> On Wed, 24 Jun 2020 at 20:25, Bill Torpey  wrote:
>> Serguei:
>> 
>> Your original question implies (but does not state explicitly) that you want 
>> to use 0mq to send shared_ptr’s to other threads in the same process.If 
>> that is the case you need to be cognizant of 
>> (https://en.cppreference.com/w/cpp/memory/shared_ptr):
>> 
>> The ownership of an object can only be shared with another shared_ptr by 
>> copy constructing or copy assigning its value to another shared_ptr. 
>> Constructing a new shared_ptr using the raw underlying pointer owned by 
>> another shared_ptr leads to undefined behavior. 
> 
> 
> 
> If that is not the case (i.e., if the destination of the send is not another 
> thread in the same process), you need to actually serialize the data, as 
> suggested by Sergei Nikulov 
> 
> Which is it?
> 
> B
> 
>> On Jun 24, 2020, at 2:06 PM, Rafał Dudycz  wrote:
>> 
>> Hi,
>> 
>> Don't you think that sending a pointer to a memory is very error prone? 
>> e.g.: object may be destroyed before the receiver gets a serialized 

Re: [zeromq-dev] Sharing socket safely between threads

[Thomas Rodgers]

>
> Well, acquiring an uncontested mutex is actually pretty cheap.  It’s when
> there’s a lot of contention on the mutex that it gets expensive.
>

Even uncontested, atomic operations are still substantially more expensive
than their non-atomic counterparts, they still generate cache coherency
traffic.

On Sun, May 13, 2018 at 8:35 AM, Bill Torpey <wallstp...@gmail.com> wrote:

>
> On May 12, 2018, at 7:50 PM, Thomas Rodgers <rodg...@twrodgers.com> wrote:
>
> 3.  Another situation is to have a single “main” thread setup all the
>> sockets at startup and then hand them off to other threads (and never touch
>> them again).  Strictly speaking you may only need a memory barrier, but
>> using a mutex in this case ensures that you don’t try to use the socket
>> concurrently from more than one thread.
>>
>
> The pattern of having a main thread set up sockets first, then handing
> them off to worker threads is, IMO, very sound, but, lets perform this
> small thought experiement -
>
> We use a mutex (I'm a C++ dev, so), std::mutex, concretely. Thread
> A acquires the mutex, initializes the socket, releases the mutex (ideally
> using one of the RAII scoped locking adapters). Thread B is then started,
> and acquires and, since we assume no further access from Thread A, simply
> holds the lock for the duration of thread_main(). If, thread A (or any
> other thread) attempted to acquire that mutex, it would deadlock, as Thread
> B now has ownership.
>
> This can be properly described as poor program behavior, from a
> contractual standpoint, you violated a fundamental assumption, so this is
> "undefined behavior" for the program. I don't think I agree with the "just
> use a mutex, it's easy and safe" logic in this design pattern.
>
> The requirement is for a "full memory fence". This is to ensure that
> Thread A completes all of it's socket setup (concretely in terms of ordered
> memory writes) before any other thread, in this case thread B, can use that
> socket (in terms of ordered memory read/writes). Issuing just the memory
> fence before ThreadB starts is sufficient to guarantee this ordering. If
> ThreadA or any other thread besides ThreadB accesses the socket after the
> memory fence, that is also undefined behavior.
>
>
> The thing the mutex buys you is that allows you to *detect* when you’ve
> broken the contract (by blocking) — the fence does not.
>
>
> If instead, you always acquire and release the mutex for each use, then
> you wouldn't have the deadlocking issue, but you are then *ALWAYS* paying
> for a pair of atomic operations you didn't really need (atomic operations
> are most decidedly not free), because you weren't comfortable understanding
> your program's lifetime and data usage model.
>
>
> Well, acquiring an uncontested mutex is actually pretty cheap.  It’s when
> there’s a lot of contention on the mutex that it gets expensive.
>
> Still, I wouldn’t suggest using a mutex to share sockets between threads,
> except in the case of a ZMQ_PUB socket I mentioned earlier.
>
>
>
>
>
>
> On Sat, May 12, 2018 at 4:08 PM, Bill Torpey <wallstp...@gmail.com> wrote:
>
>> 1. FWIW, my personal experience has been that it is safe to share a
>> ZMQ_PUB socket between threads if protected with a mutex.  Basically the
>> sequence is lock/send/unlock.
>>
>> The alternative is to have an internal zmq_proxy with inproc on one side
>> and something like TCP on the other side, which is an extra send/receive
>> hop.  I have not found that to be necessary, and I have done a *lot* of
>> testing (which has found several other edge cases).
>>
>> FWIW the docs specifically bless this approach (
>> http://zeromq.org/area:faq):
>>
>> For those situations where a dedicated socket per thread is infeasible, a
>> socket may be shared *if and only if* each thread executes a full memory
>> barrier before accessing the socket. Most languages support a Mutex or
>> Spinlock which will execute the full memory barrier on your behalf.
>>
>> and here (http://zguide.zeromq.org/page:all#Multithreading-with-ZeroMQ):
>>
>> Technically it's possible to migrate a socket from one thread to another
>> but it demands skill.
>>
>>
>> I have not tried doing that with ZMQ_SUB sockets — there is really no
>> point, as a sigle thread sitting in a zmq_poll call on multiple sockets is
>> probably the cleanest design anyway.
>>
>>
>> 2. I can definitely testify that trying to share a ZMQ_SUB socket
>> *without* mutexes is guaranteed to crash, and that trying to share a
>> ZMQ_SUB socket *with* mutexes is almost impossible 

Re: [zeromq-dev] Sharing socket safely between threads

[Thomas Rodgers]

>
> 3.  Another situation is to have a single “main” thread setup all the
> sockets at startup and then hand them off to other threads (and never touch
> them again).  Strictly speaking you may only need a memory barrier, but
> using a mutex in this case ensures that you don’t try to use the socket
> concurrently from more than one thread.
>

The pattern of having a main thread set up sockets first, then handing them
off to worker threads is, IMO, very sound, but, lets perform this small
thought experiement -

We use a mutex (I'm a C++ dev, so), std::mutex, concretely. Thread
A acquires the mutex, initializes the socket, releases the mutex (ideally
using one of the RAII scoped locking adapters). Thread B is then started,
and acquires and, since we assume no further access from Thread A, simply
holds the lock for the duration of thread_main(). If, thread A (or any
other thread) attempted to acquire that mutex, it would deadlock, as Thread
B now has ownership.

This can be properly described as poor program behavior, from a contractual
standpoint, you violated a fundamental assumption, so this is "undefined
behavior" for the program. I don't think I agree with the "just use a
mutex, it's easy and safe" logic in this design pattern.

The requirement is for a "full memory fence". This is to ensure that Thread
A completes all of it's socket setup (concretely in terms of ordered memory
writes) before any other thread, in this case thread B, can use that socket
(in terms of ordered memory read/writes). Issuing just the memory fence
before ThreadB starts is sufficient to guarantee this ordering. If ThreadA
or any other thread besides ThreadB accesses the socket after the memory
fence, that is also undefined behavior.

If instead, you always acquire and release the mutex for each use, then you
wouldn't have the deadlocking issue, but you are then *ALWAYS* paying for a
pair of atomic operations you didn't really need (atomic operations are
most decidedly not free), because you weren't comfortable understanding
your program's lifetime and data usage model.





On Sat, May 12, 2018 at 4:08 PM, Bill Torpey <wallstp...@gmail.com> wrote:

> 1. FWIW, my personal experience has been that it is safe to share a
> ZMQ_PUB socket between threads if protected with a mutex.  Basically the
> sequence is lock/send/unlock.
>
> The alternative is to have an internal zmq_proxy with inproc on one side
> and something like TCP on the other side, which is an extra send/receive
> hop.  I have not found that to be necessary, and I have done a *lot* of
> testing (which has found several other edge cases).
>
> FWIW the docs specifically bless this approach (http://zeromq.org/area:faq
> ):
>
> For those situations where a dedicated socket per thread is infeasible, a
> socket may be shared *if and only if* each thread executes a full memory
> barrier before accessing the socket. Most languages support a Mutex or
> Spinlock which will execute the full memory barrier on your behalf.
>
> and here (http://zguide.zeromq.org/page:all#Multithreading-with-ZeroMQ):
>
> Technically it's possible to migrate a socket from one thread to another
> but it demands skill.
>
>
> I have not tried doing that with ZMQ_SUB sockets — there is really no
> point, as a sigle thread sitting in a zmq_poll call on multiple sockets is
> probably the cleanest design anyway.
>
>
> 2. I can definitely testify that trying to share a ZMQ_SUB socket
> *without* mutexes is guaranteed to crash, and that trying to share a
> ZMQ_SUB socket *with* mutexes is almost impossible to do without
> deadlocking.
>
>
> 3.  Another situation is to have a single “main” thread setup all the
> sockets at startup and then hand them off to other threads (and never touch
> them again).  Strictly speaking you may only need a memory barrier, but
> using a mutex in this case ensures that you don’t try to use the socket
> concurrently from more than one thread.
>
>
> 4.  Last but not least, if you’re planning on using inproc sockets for
> inter-thread communication, you may find this helpful:
> https://github.com/WallStProg/zmqtests/tree/master/threads
>
>
> On May 8, 2018, at 3:58 PM, Thomas Rodgers <rodg...@twrodgers.com> wrote:
>
> No, not really. I have designed my zmq based systems to either -
>
> * orchestrate connections over the inproc transport
> * performed the delicate dance of explicitly passing a fresh socket to a
> fresh thread the way that czmq actors
> <http://czmq.zeromq.org/manual:zactor> work,
>   as implemented in azmq
> <https://github.com/zeromq/azmq/blob/master/azmq/detail/actor_service.hpp>
>
> On Mon, May 7, 2018 at 11:58 AM, Attila Magyari <att...@gmail.com> wrote:
>
>> This sounds promising. My concern is if ther

Re: [zeromq-dev] Sharing socket safely between threads

[Thomas Rodgers]

No, not really. I have designed my zmq based systems to either -

* orchestrate connections over the inproc transport
* performed the delicate dance of explicitly passing a fresh socket to a
fresh thread the way that czmq actors <http://czmq.zeromq.org/manual:zactor>
work,
  as implemented in azmq
<https://github.com/zeromq/azmq/blob/master/azmq/detail/actor_service.hpp>

On Mon, May 7, 2018 at 11:58 AM, Attila Magyari <att...@gmail.com> wrote:

> This sounds promising. My concern is if there are some background threads
> internally in the ZMQ library, which would use the socket out of sync with
> mine, or anything else that I'm not thinking about. I can ensure that the
> socket won't be used from multiple threads.
>
> Do you have any experience with this, or only theory?
>
> Thank you,
> Attila
>
>
> On Mon, May 7, 2018 at 5:49 PM Thomas Rodgers <rodg...@twrodgers.com>
> wrote:
>
>> The zmq docs say you need to ensure a ‘full fence’ a mutex is one way of
>> achieving that.
>>
>> If you are using C++ (-std=c++11 or later) and you can guarantee there is
>> no racy usage from another thread, you can issue a memory fence using -
>>
>> std::atomic_thread_fence
>>
>> On Mon, May 7, 2018 at 8:42 AM Attila Magyari <att...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I know that zmq sockets are not thread safe. However I can't think of a
>>> good design (explained below) without using the socket in several threads.
>>> What I want to do is connect the socket in a thread, and then use it in a
>>> different one until the end, and never in parallel between several threads.
>>> I will guard the access with a mutex as well. Do you think this will be
>>> safe?
>>>
>>> Just in case someone might have a better idea for my design, here is
>>> what I'm trying to do:
>>> I have an application which starts another process, passes a port to the
>>> newly created process, so it can connect back to the main application
>>> through a ZMQ_PAIR socket. Both processes are local to the machine. The
>>> main application will request from the second one, but the second one can
>>> initiate messages without an explicit request as well. Do you have a nicer
>>> design to achieve something like this?
>>>
>>> Thank you in advance!
>>>
>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Sharing socket safely between threads

[Thomas Rodgers]

The zmq docs say you need to ensure a ‘full fence’ a mutex is one way of
achieving that.

If you are using C++ (-std=c++11 or later) and you can guarantee there is
no racy usage from another thread, you can issue a memory fence using -

std::atomic_thread_fence

On Mon, May 7, 2018 at 8:42 AM Attila Magyari  wrote:

> Hello,
>
> I know that zmq sockets are not thread safe. However I can't think of a
> good design (explained below) without using the socket in several threads.
> What I want to do is connect the socket in a thread, and then use it in a
> different one until the end, and never in parallel between several threads.
> I will guard the access with a mutex as well. Do you think this will be
> safe?
>
> Just in case someone might have a better idea for my design, here is what
> I'm trying to do:
> I have an application which starts another process, passes a port to the
> newly created process, so it can connect back to the main application
> through a ZMQ_PAIR socket. Both processes are local to the machine. The
> main application will request from the second one, but the second one can
> initiate messages without an explicit request as well. Do you have a nicer
> design to achieve something like this?
>
> Thank you in advance!
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] are zmq::atomic_ptr_t<> Helgrind warnings known?

[Thomas Rodgers]

I don’t know if this has changed recently, but at the time I added the
compiler intrinsics support, it was generally deemed undesirable to require
C++11.

On Fri, Feb 23, 2018 at 5:22 AM Francesco 
wrote:

> Hi all,
> I'm trying to further debug the problem I described in my earlier mail (
> https://lists.zeromq.org/pipermail/zeromq-dev/2018-February/032303.html)
> so I decided to use Helgrind to find race conditions in my code.
>
> My problem is that apparently Helgrind 3.12.0 is reporting race conditions
> against zmq::atomic_ptr_t<> implementation.
> Now I know that Helgrind has troubles with C++11 atomics but by looking at
> the code I see that ZMQ is not using them (note: I do have
> ZMQ_ATOMIC_PTR_CXX11 defined but I also have ZMQ_ATOMIC_PTR_INTRINSIC
> defined, so the latter wins!).
>
> In particular Helgrind 3.12.0 tells me that:
>
>
> ==00:00:00:11.885 29399==
> ==00:00:00:11.885 29399== *Possible data race during read of size 8 at
> 0xB373BF0 by thread #4*
> ==00:00:00:11.885 29399== Locks held: none
> ==00:00:00:11.885 29399==at 0x6BD79AB:
> *zmq::atomic_ptr_t::cas*(zmq::command_t*,
> zmq::command_t*) (atomic_ptr.hpp:150)
> ==00:00:00:11.885 29399==by 0x6BD7874: zmq::ypipe_t 16>::check_read() (ypipe.hpp:147)
> ==00:00:00:11.885 29399==by 0x6BD7288: zmq::ypipe_t 16>::read(zmq::command_t*) (ypipe.hpp:165)
> ==00:00:00:11.885 29399==by 0x6BD6FE7:
> zmq::mailbox_t::recv(zmq::command_t*, int) (mailbox.cpp:98)
> ==00:00:00:11.885 29399==by 0x6BD29FC: zmq::io_thread_t::in_event()
> (io_thread.cpp:81)
> ==00:00:00:11.885 29399==by 0x6BD05C1: zmq::epoll_t::loop()
> (epoll.cpp:188)
> ==00:00:00:11.885 29399==by 0x6BD06C3:
> zmq::epoll_t::worker_routine(void*) (epoll.cpp:203)
> ==00:00:00:11.885 29399==by 0x6C18BA5: thread_routine (thread.cpp:109)
> ==00:00:00:11.885 29399==by 0x4C2F837: mythread_wrapper
> (hg_intercepts.c:389)
> ==00:00:00:11.885 29399==by 0x6E72463: start_thread
> (pthread_create.c:334)
> ==00:00:00:11.885 29399==by 0x92F901C: clone (clone.S:109)
> ==00:00:00:11.885 29399==
> ==00:00:00:11.885 29399== This conflicts with a previous write of size 8
> by thread #2
> ==00:00:00:11.885 29399== Locks held: 1, at address 0xB373C08
> ==00:00:00:11.885 29399==at 0x6BD77F4:
> *zmq::atomic_ptr_t::set*(zmq::command_t*)
> (atomic_ptr.hpp:90)
> ==00:00:00:11.885 29399==by 0x6BD7422: zmq::ypipe_t 16>::flush() (ypipe.hpp:125)
> ==00:00:00:11.885 29399==by 0x6BD6DF5:
> zmq::mailbox_t::send(zmq::command_t const&) (mailbox.cpp:63)
> ==00:00:00:11.885 29399==by 0x6BB9128:
> zmq::ctx_t::send_command(unsigned int, zmq::command_t const&) (ctx.cpp:438)
> ==00:00:00:11.885 29399==by 0x6BE34CE:
> zmq::object_t::send_command(zmq::command_t&) (object.cpp:474)
> ==00:00:00:11.885 29399==by 0x6BE26F8:
> zmq::object_t::send_plug(zmq::own_t*, bool) (object.cpp:220)
> ==00:00:00:11.885 29399==by 0x6BE68E2:
> zmq::own_t::launch_child(zmq::own_t*) (own.cpp:87)
> ==00:00:00:11.885 29399==by 0x6C03D6C:
> zmq::socket_base_t::add_endpoint(char const*, zmq::own_t*, zmq::pipe_t*)
> (socket_base.cpp:1006)
> ==00:00:00:11.885 29399==  Address 0xb373bf0 is 128 bytes inside a block
> of size 224 alloc'd
> ==00:00:00:11.885 29399==at 0x4C2A6FD: operator new(unsigned long,
> std::nothrow_t const&) (vg_replace_malloc.c:376)
> ==00:00:00:11.885 29399==by 0x6BB8B8D: zmq::ctx_t::create_socket(int)
> (ctx.cpp:351)
> ==00:00:00:11.885 29399==by 0x6C284D5: zmq_socket (zmq.cpp:267)
> ==00:00:00:11.885 29399==by 0x6143809:
> ZmqClientSocket::Config(PubSubSocketConfig const&) (ZmqRequestReply.cpp:303)
> ==00:00:00:11.885 29399==by 0x6144069:
> ZmqClientMultiSocket::Config(PubSubSocketConfig const&)
> (ZmqRequestReply.cpp:407)
> ==00:00:00:11.885 29399==by 0x61684EF: client_thread_main(void*)
> (ZmqRequestReplyUnitTests.cpp:132)
> ==00:00:00:11.886 29399==by 0x4C2F837: mythread_wrapper
> (hg_intercepts.c:389)
> ==00:00:00:11.886 29399==by 0x6E72463: start_thread
> (pthread_create.c:334)
> ==00:00:00:11.886 29399==by 0x92F901C: clone (clone.S:109)
> ==00:00:00:11.886 29399==  Block was alloc'd by thread #2
>
>
> Is this a known (and ignorable) issue with  zmq::atomic_ptr_t<>?
>
> Thanks,
> Francesco
>
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Building C++ binding zmq - zmqpp step

[Thomas Rodgers]

Outstanding!

On Mon, Feb 5, 2018 at 4:26 PM Bernardo Augusto García Loaiza <
botib...@gmail.com> wrote:

> Thanks Thomas.
>
> I've install the  libboost-test-dev with apt-get in my machine and all
> it's works
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Communication between C++ zmq client and Python zmq Server

[Thomas Rodgers]

<>

Is this correct?


Yes


> 1. What advantages do I have when using something like protocol buffer to
> serialization data instead of
> send the data of a basic way such as I perform here turn the data to
> string and sending it?
>

If you want to send complex data structures, portably between different
programming language environments and processor architectures.
This is not a goal of ZeroMQ and is explicitly left to other libraries and
tools.

| 2.  Why use memcpy is bad or not suited?

http://en.cppreference.com/w/cpp/algorithm/copy
http://en.cppreference.com/w/cpp/algorithm/copy_n

are better alternatives in C++ and as, or more efficient than ::memcpy
(they in fact delegate, as inline code to ::memcpy if that is the fastest
way to perform the copy).

your example would read -

#include 

...

std::copy_n(result.c_str(), result.size() + 1, request.data());

OR

std::copy(result.begin(), result.size(), request.data());

On Wed, Jan 31, 2018 at 12:33 PM, Bernardo Augusto García Loaiza <
botib...@gmail.com> wrote:

> Hi Thomas, thanks for your appreciations
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Building C++ binding zmq - zmqpp step

[Thomas Rodgers]

Please consult
http://www.boost.org/doc/libs/1_66_0/more/getting_started/index.html and
your operating system's package manager, where you may find a prepackaged
version of Boost for your platform

On Fri, Feb 2, 2018 at 4:32 PM, Bernardo Augusto García Loaiza <
botib...@gmail.com> wrote:

> Hi ZMQ people.
>
> I am building the c++ binding zmq and I have this inconvenient which I've
> entered as a issue  in the
> zmqpp repository  
>
> In the building process,  I have the problem
>
> ++  -o ./build/max-g++/zmqpp-tests  ./build/max-g++/obj/tests/test_inet.o  
> ./build/max-g++/obj/tests/test_z85.o  
> ./build/max-g++/obj/tests/test_context.o  
> ./build/max-g++/obj/tests/test_message.o  
> ./build/max-g++/obj/tests/test_auth.o  ./build/max-g++/obj/tests/test_actor.o 
>  ./build/max-g++/obj/tests/test_load.o  
> ./build/max-g++/obj/tests/test_proxy.o  ./build/max-g++/obj/tests/test_loop.o 
>  ./build/max-g++/obj/tests/test_socket_options.o  
> ./build/max-g++/obj/tests/test_socket.o  
> ./build/max-g++/obj/tests/test_reactor.o  
> ./build/max-**g++/obj/tests/test_sanity.o  
> ./build/max-g++/obj/tests/test_message_stream.o  
> ./build/max-g++/obj/tests/test_poller.o -L./build/max-g++ -lzmqpp 
> -lboost_unit_test_framework -lpthread -lzmq
> /usr/bin/ld: cannot find -lboost_unit_test_framework
> collect2: error: ld returned 1 exit status
> Makefile:195: recipe for target 'zmqpp-tests' failed**
> make: *** [zmqpp-tests] Error 1
>
> How to can I add or install or setup the -lboost_unit_test_framework library
> ? ... just in case that I am in right in my appreciation problem ...
>
>
> Bernardo Augusto García Loaiza
> Ingeniero de Sistemas
> Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
> http://about.me/bgarcial
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Communication between C++ zmq client and Python zmq Server

[Thomas Rodgers]

You can’t memcpy a std::string, and in fact, you should t be using memcpy
in general in C++. I won’t go into the why of all of that here, but start
by changing -

memcpy(request.data(), **, 30);

To

memcpy(request.data(), *result.c_str()*, result.size() + 1);


On Tue, Jan 30, 2018 at 4:46 PM Bernardo Augusto García Loaiza <
botib...@gmail.com> wrote:

> Hi, I again.
>
> I've performed some small test in relation to the way on how to I sending
> the data member structure.
>
> I am turning the int data member structure to string before to be send it
> ..
> In the following code section  I am turn btnState in string data and
> assign it to string s variable and I contatenated it some additional string
> content and
> I sending this string concatenated result:
>
> void ZMQComponent::instrumentDataSend(instrumentData a){
> /*  Initialize the data members structure instrumentData */
> a.pos = sofa::defaulttype::Vec3d(1.0f, 1.0f, 1.0f);
> a.quat = defaulttype::Quat(1.0f, 1.0f, 4.0f, 1.0f);
> a.btnState = 5671;
> a.openInst = 1.0f;
> a.blnDataReady = false;
>
>
>
>* string s, test, result, d;
> s = to_string(a.btnState);
> test = " is a number";
> result = s + test;*
>
>
>
> /*  We send  the btnState data  */
>
>
> zmq::message_t request(30);
>
>
>
>
> /*  We ask for the memory address to ge the btnState content and send it. */
>
>
> memcpy(request.data(), **, 30);
> socket.send(request);}
>
>
> The output or the message which arrive to python zmq server is the content
> of
> result variable (btnState turn to string in s content variable + string
> test concatenated)
> and some symbols characters of the :
>
> (cnvss_test) ➜  Python git:(ZMQCommunication) ✗ python server.py
> ZMQ Server listening ...
>
> *Received message from Sofa: 
> b'\xb0\x1d\x19\xf4\xfd\x7f\x00\x00\x0e\x00\x00\x00\x00\x00\x00\x0045 is a 
> number'*
>
> If I assign a value less than 30 in the request, by example zmq::message_t
> request(10) the output in my server is:
>
> Received message from Sofa: b'\x90\x94\xa1\x00\xfc\x7f\x00\x00\x0e\x00'
>
> If I assign a value greater than 10 in the request, by example zmq::message_t
> request(20) the output in my server is:
>
> Received message from Sofa: 
> b'\x80$(\xc7\xfc\x7f\x00\x00\x0e\x00\x00\x00\x00\x00\x00\x00*45 i*
>
> Then, the string or object which I receive in the server side, it has as
> long as the length or size assigned to zmq::message_t request variable
>
>
> Based in the above mentioned, is ZMQ whom add this strings in my message
> received?
>
> According to the previous process, my message is arrived to my server,
>
> then 
>
>
>  is correct attempt what the serialization process with some entity like
> protocol buffer is necessary?
>
>
>  I understand that use something like google protocol buffer allow have
> some correlation more controlled in relation to objects sent and the
> objects received in relation of their real content ...
>
> In any case, how to can I remove the strings or characters symbols that
> are added in the message arrived to the server?
>
>
>
>
>
>
>
>
> Bernardo Augusto García Loaiza
> Ingeniero de Sistemas
> Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
> http://about.me/bgarcial
>
>
> On Sat, Jan 27, 2018 at 11:24 AM, Thomas Rodgers <rodg...@twrodgers.com>
> wrote:
>
>> “strat team” was supposed to be std::stringstream (Thanks for nothing
>> autocorrect!)
>>
>> http://en.cppreference.com/w/cpp/io/basic_stringstream
>>
>> On Sat, Jan 27, 2018 at 10:22 AM Thomas Rodgers <rodg...@twrodgers.com>
>> wrote:
>>
>>> Strings are the simplest. If you don’t need to parse the data on the C++
>>> side, just format it as a JSON map on the C++ side, stream it into a strat
>>> team, send the resulting string on the socket and use Python’s support for
>>> parsing JSON on the received strong. For instance.
>>>
>>> You can also send structured binary to Python, as I mentioned; the
>>> Python CTypes module (included with Python) will let you define accessors
>>> for that data. As long as the sending and receiving side are the same CPU
>>> architecture you don’t have to worry about endianess conversions.
>>>
>>> On Sat, Jan 27, 2018 at 9:13 AM Bernardo Augusto García Loaiza <
>>> botib...@gmail.com> wrote:
>>>
>>>> Hi Luca, this mean, then, with structured string or data is necessary
>>>> some middleware entity like GPB such as Thomas tell us ...
>>>&g

Re: [zeromq-dev] Communication between C++ zmq client and Python zmq Server

[Thomas Rodgers]

“strat team” was supposed to be std::stringstream (Thanks for nothing
autocorrect!)

http://en.cppreference.com/w/cpp/io/basic_stringstream

On Sat, Jan 27, 2018 at 10:22 AM Thomas Rodgers <rodg...@twrodgers.com>
wrote:

> Strings are the simplest. If you don’t need to parse the data on the C++
> side, just format it as a JSON map on the C++ side, stream it into a strat
> team, send the resulting string on the socket and use Python’s support for
> parsing JSON on the received strong. For instance.
>
> You can also send structured binary to Python, as I mentioned; the Python
> CTypes module (included with Python) will let you define accessors for that
> data. As long as the sending and receiving side are the same CPU
> architecture you don’t have to worry about endianess conversions.
>
> On Sat, Jan 27, 2018 at 9:13 AM Bernardo Augusto García Loaiza <
> botib...@gmail.com> wrote:
>
>> Hi Luca, this mean, then, with structured string or data is necessary
>> some middleware entity like GPB such as Thomas tell us ...
>>
>>
>> Bernardo Augusto García Loaiza
>> Ingeniero de Sistemas
>> Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
>> http://about.me/bgarcial
>>
>>
>> On Sat, Jan 27, 2018 at 10:07 AM, Luca Boccassi <luca.bocca...@gmail.com>
>> wrote:
>>
>>> Yes you can just send unstructured binary data or strings - Python has
>>> native helpers for strings, and CZMQ as well
>>>
>>> On Fri, 2018-01-26 at 21:27 -0500, Bernardo Augusto García Loaiza
>>> wrote:
>>> > Thomas, I understand perfectly your explanation. But I want share
>>> > with you
>>> > another similar case, just for curiosity or to receive some
>>> > additional
>>> > orientation about it.
>>> >
>>> > I have a script client C++ ZEROMQ  as a documentation, and I have
>>> > script
>>> > server python, together based in the documentation zeromq website.
>>> > This mean, together are scripts basics
>>> >
>>> > From C++ client I am sending the string message
>>> > <https://github.com/bgarcial/zeroMQ_Client/blob/master/client.cpp#L27
>>> > >  and
>>> > I have a python server which receive this string message client
>>> > <https://github.com/bgarcial/zeroMQ_Client/blob/master/Python/server.
>>> > py#L20>
>>> > of  a direct way and show me their content
>>> >
>>> > In this basic sample (documentation zmq based) I am not
>>> > using  structures
>>> > data  members. Is for this reason that in this case I receive and I
>>> > can see
>>> > the content of the client message in the zmq server side without have
>>> > use
>>> > something like Google Protocol Buffer, This mean, is because in this
>>> > case I
>>> > am not sending any structures data  members?
>>> >
>>> > I appreciate one more your orientation
>>> >
>>> >
>>> > Bernardo Augusto García Loaiza
>>> > Ingeniero de Sistemas
>>> > Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
>>> > http://about.me/bgarcial
>>> >
>>> >
>>> > On Fri, Jan 26, 2018 at 7:44 AM, Thomas Rodgers <rodg...@twrodgers.co
>>> > m>
>>> > wrote:
>>> >
>>> > > Short answer yes, it’s related to different languages. TCP and
>>> > > ZeroMQ only
>>> > > deal with transport and framing of messages (respectively) Python
>>> > > has no
>>> > > idea that that 10 bytes corresponds to a C/C++ struct of a given
>>> > > layout
>>> > > until you tell it. Different platforms (CPU architectures) have
>>> > > potentially
>>> > > different representations of fundamental types.
>>> > >
>>> > > On Thu, Jan 25, 2018 at 4:37 PM Bernardo Augusto García Loaiza <
>>> > > botib...@gmail.com> wrote:
>>> > >
>>> > > > One more question. Why is necessary the serialization process? It
>>> > > > is
>>> > > > assumed that zeromq works via TCP and in the TCP protocol, the
>>> > > > data does
>>> > > > not undergo any transformation? This is related with the fact of
>>> > > > that I
>>> > > > have different platform/languages?
>>> > > >
>>> > > > On Thu, Jan 25, 2018 at 4:45 PM Be

Re: [zeromq-dev] Communication between C++ zmq client and Python zmq Server

[Thomas Rodgers]

Strings are the simplest. If you don’t need to parse the data on the C++
side, just format it as a JSON map on the C++ side, stream it into a strat
team, send the resulting string on the socket and use Python’s support for
parsing JSON on the received strong. For instance.

You can also send structured binary to Python, as I mentioned; the Python
CTypes module (included with Python) will let you define accessors for that
data. As long as the sending and receiving side are the same CPU
architecture you don’t have to worry about endianess conversions.

On Sat, Jan 27, 2018 at 9:13 AM Bernardo Augusto García Loaiza <
botib...@gmail.com> wrote:

> Hi Luca, this mean, then, with structured string or data is necessary some
> middleware entity like GPB such as Thomas tell us ...
>
>
> Bernardo Augusto García Loaiza
> Ingeniero de Sistemas
> Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
> http://about.me/bgarcial
>
>
> On Sat, Jan 27, 2018 at 10:07 AM, Luca Boccassi <luca.bocca...@gmail.com>
> wrote:
>
>> Yes you can just send unstructured binary data or strings - Python has
>> native helpers for strings, and CZMQ as well
>>
>> On Fri, 2018-01-26 at 21:27 -0500, Bernardo Augusto García Loaiza
>> wrote:
>> > Thomas, I understand perfectly your explanation. But I want share
>> > with you
>> > another similar case, just for curiosity or to receive some
>> > additional
>> > orientation about it.
>> >
>> > I have a script client C++ ZEROMQ  as a documentation, and I have
>> > script
>> > server python, together based in the documentation zeromq website.
>> > This mean, together are scripts basics
>> >
>> > From C++ client I am sending the string message
>> > <https://github.com/bgarcial/zeroMQ_Client/blob/master/client.cpp#L27
>> > >  and
>> > I have a python server which receive this string message client
>> > <https://github.com/bgarcial/zeroMQ_Client/blob/master/Python/server.
>> > py#L20>
>> > of  a direct way and show me their content
>> >
>> > In this basic sample (documentation zmq based) I am not
>> > using  structures
>> > data  members. Is for this reason that in this case I receive and I
>> > can see
>> > the content of the client message in the zmq server side without have
>> > use
>> > something like Google Protocol Buffer, This mean, is because in this
>> > case I
>> > am not sending any structures data  members?
>> >
>> > I appreciate one more your orientation
>> >
>> >
>> > Bernardo Augusto García Loaiza
>> > Ingeniero de Sistemas
>> > Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
>> > http://about.me/bgarcial
>> >
>> >
>> > On Fri, Jan 26, 2018 at 7:44 AM, Thomas Rodgers <rodg...@twrodgers.co
>> > m>
>> > wrote:
>> >
>> > > Short answer yes, it’s related to different languages. TCP and
>> > > ZeroMQ only
>> > > deal with transport and framing of messages (respectively) Python
>> > > has no
>> > > idea that that 10 bytes corresponds to a C/C++ struct of a given
>> > > layout
>> > > until you tell it. Different platforms (CPU architectures) have
>> > > potentially
>> > > different representations of fundamental types.
>> > >
>> > > On Thu, Jan 25, 2018 at 4:37 PM Bernardo Augusto García Loaiza <
>> > > botib...@gmail.com> wrote:
>> > >
>> > > > One more question. Why is necessary the serialization process? It
>> > > > is
>> > > > assumed that zeromq works via TCP and in the TCP protocol, the
>> > > > data does
>> > > > not undergo any transformation? This is related with the fact of
>> > > > that I
>> > > > have different platform/languages?
>> > > >
>> > > > On Thu, Jan 25, 2018 at 4:45 PM Bernardo Augusto García Loaiza <
>> > > > botib...@gmail.com> wrote:
>> > > >
>> > > > > Hi Thomas,
>> > > > > Thanks for your illustrative response
>> > > > >
>> > > > > I'll look Google Protocol Buffers. My sender is from C++
>> > > > > language and
>> > > > > my reception is Python. What sort of installation recommend me
>> > > > > you?
>> > > > > Binaries or build protocol buffer along my C++ runtime? or o
>> 

Re: [zeromq-dev] Communication between C++ zmq client and Python zmq Server

[Thomas Rodgers]

Short answer yes, it’s related to different languages. TCP and ZeroMQ only
deal with transport and framing of messages (respectively) Python has no
idea that that 10 bytes corresponds to a C/C++ struct of a given layout
until you tell it. Different platforms (CPU architectures) have potentially
different representations of fundamental types.

On Thu, Jan 25, 2018 at 4:37 PM Bernardo Augusto García Loaiza <
botib...@gmail.com> wrote:

> One more question. Why is necessary the serialization process? It is
> assumed that zeromq works via TCP and in the TCP protocol, the data does
> not undergo any transformation? This is related with the fact of that I
> have different platform/languages?
>
> On Thu, Jan 25, 2018 at 4:45 PM Bernardo Augusto García Loaiza <
> botib...@gmail.com> wrote:
>
>> Hi Thomas,
>> Thanks for your illustrative response
>>
>> I'll look Google Protocol Buffers. My sender is from C++ language and my
>> reception is Python. What sort of installation recommend me you? Binaries
>> or build protocol buffer along my C++ runtime? or o build protoc binary
>> from source?
>>
>> On Wed, Jan 24, 2018 at 8:36 PM Thomas Rodgers <rodg...@twrodgers.com>
>> wrote:
>>
>>> You can have a look at Python’s ctypes module, which will let you define
>>> a ‘struct’ from Python with the same layout as your C++ struct.
>>>
>>> You can also investigate any number of serialization libraries that have
>>> C++ and Python support, eg ProtoBufs or Thrift, or MagPack or whatever.
>>>
>>> On Wed, Jan 24, 2018 at 5:26 PM Bernardo Augusto García Loaiza <
>>> botib...@gmail.com> wrote:
>>>
>>>> Hi, ZMQ people.
>>>> Greetings.
>>>>
>>>>
>>>> I have a  C++ zeromq client process in which I am sending some data
>>>> members structures
>>>>
>>>> *ZMQComponent.h* file
>>>>
>>>>
>>>> #include 
>>>> #include 
>>>>
>>>> // To Quat datatype
>>>> #include 
>>>> using sofa::defaulttype::Quat;
>>>>
>>>> using std::string;
>>>>
>>>> namespace sofa
>>>> {
>>>>
>>>> namespace component
>>>> {
>>>>
>>>> namespace controller
>>>> {
>>>>
>>>> /* data structure which I want send data to python zmq server */
>>>> struct instrumentData
>>>> {
>>>> typedef sofa::defaulttype::Vec3d Vec3d;
>>>> Vec3d pos;
>>>> Quat quat;
>>>> int btnState;
>>>> float openInst;
>>>> bool blnDataReady;
>>>> };
>>>>
>>>> class ZMQComponent : public sofa::core::behavior::BaseController
>>>> {
>>>> public:
>>>> SOFA_CLASS(ZMQComponent, sofa::core::behavior::BaseController);
>>>>
>>>> ZMQComponent();
>>>> virtual ~ZMQComponent();
>>>> /* Conect to ZMQ external python Server */
>>>> void setupConnection();
>>>>
>>>> /* Send some data memeber instrumentData structure to ZMQ external
>>>> Server */
>>>> void instrumentDataSend(instrumentData a);
>>>>
>>>> /* initialize function */
>>>> void init();
>>>>
>>>> };
>>>>
>>>> } // namespace sofa
>>>>
>>>> } // namespace component
>>>>
>>>> } // namespace controller
>>>>
>>>>
>>>> The *ZMQComponent.cpp* is:
>>>>
>>>> #include 
>>>> #include 
>>>> #include 
>>>> #include 
>>>> #include "ZMQComponent.h"
>>>>
>>>>
>>>> using namespace std;
>>>>
>>>> namespace sofa
>>>> {
>>>>
>>>> namespace component
>>>> {
>>>>
>>>> namespace controller
>>>> {
>>>>
>>>> /* ZMQ Internal Client context and socket */
>>>> zmq::context_t context(1);
>>>> zmq::socket_t socket(context, ZMQ_REQ);
>>>>
>>>> ZMQComponent::ZMQComponent(){}
>>>>
>>>> void ZMQComponent::setupConnection()
>>>> {
>>>> cout << "Connecting to python zeroMQ server ..." << endl;
>>>> socket.connect("tcp://localhost:");
>>>> }
>>>>
>>>> void ZMQComponent::instrumentDataSend(instrumentData a)

Re: [zeromq-dev] Communication between C++ zmq client and Python zmq Server

[Thomas Rodgers]

You can have a look at Python’s ctypes module, which will let you define a
‘struct’ from Python with the same layout as your C++ struct.

You can also investigate any number of serialization libraries that have
C++ and Python support, eg ProtoBufs or Thrift, or MagPack or whatever.

On Wed, Jan 24, 2018 at 5:26 PM Bernardo Augusto García Loaiza <
botib...@gmail.com> wrote:

> Hi, ZMQ people.
> Greetings.
>
>
> I have a  C++ zeromq client process in which I am sending some data
> members structures
>
> *ZMQComponent.h* file
>
>
> #include 
> #include 
>
> // To Quat datatype
> #include 
> using sofa::defaulttype::Quat;
>
> using std::string;
>
> namespace sofa
> {
>
> namespace component
> {
>
> namespace controller
> {
>
> /* data structure which I want send data to python zmq server */
> struct instrumentData
> {
> typedef sofa::defaulttype::Vec3d Vec3d;
> Vec3d pos;
> Quat quat;
> int btnState;
> float openInst;
> bool blnDataReady;
> };
>
> class ZMQComponent : public sofa::core::behavior::BaseController
> {
> public:
> SOFA_CLASS(ZMQComponent, sofa::core::behavior::BaseController);
>
> ZMQComponent();
> virtual ~ZMQComponent();
> /* Conect to ZMQ external python Server */
> void setupConnection();
>
> /* Send some data memeber instrumentData structure to ZMQ external Server
> */
> void instrumentDataSend(instrumentData a);
>
> /* initialize function */
> void init();
>
> };
>
> } // namespace sofa
>
> } // namespace component
>
> } // namespace controller
>
>
> The *ZMQComponent.cpp* is:
>
> #include 
> #include 
> #include 
> #include 
> #include "ZMQComponent.h"
>
>
> using namespace std;
>
> namespace sofa
> {
>
> namespace component
> {
>
> namespace controller
> {
>
> /* ZMQ Internal Client context and socket */
> zmq::context_t context(1);
> zmq::socket_t socket(context, ZMQ_REQ);
>
> ZMQComponent::ZMQComponent(){}
>
> void ZMQComponent::setupConnection()
> {
> cout << "Connecting to python zeroMQ server ..." << endl;
> socket.connect("tcp://localhost:");
> }
>
> void ZMQComponent::instrumentDataSend(instrumentData a)
> {
> /* Initialize the data members structure instrumentData */
> a.pos = sofa::defaulttype::Vec3d(1.0f, 1.0f, 1.0f);
> a.quat = defaulttype::Quat(1.0f, 1.0f, 4.0f, 1.0f);
> a.btnState = 5671;
> a.openInst = 1.0f;
> a.blnDataReady = false;
>
> /* We send the btnState data */
> zmq::message_t request(10);
> cout << "The data are: " << a.btnState;
>
> /* We ask for the memory address to ge the btnState content and send it. */
> memcpy(request.data(), , 10);
> socket.send(request);
> }
>
>
> /* In the init function we create the objects to setup connection and send
> data */
> void ZMQComponent::init()
> {
> std::cout << "ZeroMQCommunication::init()" << std::endl;
> ZMQComponent z;
> z.setupConnection();
>
> instrumentData itemp;
> z.instrumentDataSend(itemp);
> }
>
> /* Other code related  */
> ZMQComponent::~ZMQComponent(){}
>
> // int ZeroMqComponentClass = sofa::core::RegisterObject("This component
> does nothing.").add();
> SOFA_DECL_CLASS(ZMQServerComponent)
>
> int ZMQServerComponentClass = sofa::core::RegisterObject("This component
> create a Socket.").add< ZMQServerComponent >();
> } // namespace controller
>
> } // namespace component
>
> } // namespace sofa
>
> Then , my python zmq server  which receive the *btnState*  int variable
> is:
>
> import time
> import zmq
>
> context = zmq.Context()
> socket = context.socket(zmq.REP)
> socket.bind("tcp://*:")
> print('ZMQ Server listening ... ')
>
> while True:
> # Wait for next request from client
> message = socket.recv()
> print("Received message from Sofa: {}".format(message))
> # print("Received message from c++ %s" % message)
>
> # Do some 'work'
> time.sleep(1)
>
> # Send reply back to client
> # socket.send(b"Hola cliente, muy bien y tu ?")
> # print('Response sent')
>
>
>
> The output or the message which arrive to python zmq server is the symbols
> characters of the btnState:
>
> (cnvss_test) ➜  Python git:(ZMQCommunication) ✗ python server.py
> ZMQ Server listening ...
> *Received message from Sofa: b"\x00'\x84)\xff\x7f\x00\x00\x98&*"
>
> Likely, As I in my python server I am representing like  a string message
> arrived and I am sending from my c++ client a int btnState data,
> then I try convert int to string in  the python server side:
>
> And I replace this line
>
> print("Received message from Sofa: {}".format(message))
>
> by thiis line
>
> print("Received message from c++ %s" % str(message))
>
> But my output is:
>
> (cnvss_test) ➜  Python git:(ZMQCommunication) ✗ python server.py
> ZMQ Server listening ...
> *Received message from c++ b'\x00^n&\xff\x7f\x00\x00\xd8\\'*
> Traceback (most recent call last):
>   File "server.py", line 19, in 
> message = socket.recv()
>   File "zmq/backend/cython/socket.pyx", line 693, in
> zmq.backend.cython.socket.Socket.recv
>   File "zmq/backend/cython/socket.pyx", line 727, in
> zmq.backend.cython.socket.Socket.recv
>   File "zmq/backend/cython/socket.pyx", 

Re: [zeromq-dev] Is shared ownership possible while sending with zero-copy?

[Thomas Rodgers]

If values are small (<32 bytes) then there are no allocations, as the
message type holds that much data directly.

On Thu, Aug 31, 2017 at 1:54 PM, Patrik VV. <pad...@gmail.com> wrote:

> I'm just curious, how large are those sensor values, how many do you keep
> around, and to how many other robots do you intend to send them?
>
> Could it be premature optimization? Just asking because maybe it's not
> worth the extra effort to make it zero-copy. Just copy and pass ownership
> to ZMQ.
>
> Regards, Patrik
>
> On 31 Aug 2017, at 20:06, Thomas Rodgers <rodg...@twrodgers.com> wrote:
>
> Unfortunately that's not possible, libzmq exposes only a C API, and even
> though it is implemented in C++, it deliberately targets pre-C++11
> compilers.
>
> Further to the 'mark and sweep' idea, or more generally, deferred
> reclamation. You could have the callback place the message to be freed on a
> (possibly lock free, Boost has a handy one) queue and signal a 'reaper'
> thread (waiting on a condition_variable). The reaper thread wakes up,
> reclaims all queued message buffers then returns to waiting.
>
> On Thu, Aug 31, 2017 at 10:55 AM Stephan Opfer <op...@vs.uni-kassel.de>
> wrote:
>
>> > Another, more complicated way, would be to implement a mark
>> > garbage collector of sorts: instead of freeing the buffer, the callback
>> > you register with zmq_msg_init_data would mark the buffer as done (in a
>> > thread safe way!). Then your application's garbage collector can sweep
>> > it.
>>
>> It would be nice, if I could pass over a copy  of (not reference or
>> pointer to) a shared_ptr that owns the buffer, but with the call back and
>> the "void * hint" this wasn't possible for me.
>>
>> --
>> Distributed Systems Research Group
>> Stephan Opfer  T. +49 561 804-6280 <+49%20561%208046280>  F. +49 561
>> 804-6277 <+49%20561%208046277>
>> Univ. Kassel,  FB 16,  Wilhelmshöher Allee 73,  D-34121 Kassel
>> WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Is shared ownership possible while sending with zero-copy?

[Thomas Rodgers]

Unfortunately that's not possible, libzmq exposes only a C API, and even
though it is implemented in C++, it deliberately targets pre-C++11
compilers.

Further to the 'mark and sweep' idea, or more generally, deferred
reclamation. You could have the callback place the message to be freed on a
(possibly lock free, Boost has a handy one) queue and signal a 'reaper'
thread (waiting on a condition_variable). The reaper thread wakes up,
reclaims all queued message buffers then returns to waiting.

On Thu, Aug 31, 2017 at 10:55 AM Stephan Opfer 
wrote:

> > Another, more complicated way, would be to implement a mark
> > garbage collector of sorts: instead of freeing the buffer, the callback
> > you register with zmq_msg_init_data would mark the buffer as done (in a
> > thread safe way!). Then your application's garbage collector can sweep
> > it.
>
> It would be nice, if I could pass over a copy  of (not reference or
> pointer to) a shared_ptr that owns the buffer, but with the call back and
> the "void * hint" this wasn't possible for me.
>
> --
> Distributed Systems Research Group
> Stephan Opfer  T. +49 561 804-6280  F. +49 561 804-6277
> Univ. Kassel,  FB 16,  Wilhelmshöher Allee 73,  D-34121 Kassel
> WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ integration with GLib main event loop

[Thomas Rodgers]

I don't know that this is any less complicated (and it's C++, not C), but
azmq integrates libzmq FD handling with Boost Asio's event loop, and that
can be 'manually' pumped by calling io_service::poll_one() from inside
another event dispatch loop.

https://github.com/zeromq/azmq


On Thu, Jul 27, 2017 at 9:37 AM Luca Boccassi 
wrote:

> glib is ridiculously complicated.
>
> When we had to use it what we did was creating a GIOChannel from the
> file descriptor (again this is from ZMQ_FD, not just the socket) with
> g_io_channel_unix_new, then creating a GSource from that with
> g_io_create_watch, then attaching the callback to the source with
> g_source_set_callback, and then finally attaching the source to the
> g_task with g_task_attach_source.
>
> This worked fine and we shipped a few releases using it.
>
> On Thu, 2017-07-27 at 17:03 +0300, Alexander Yanin wrote:
> > Hi,
> >
> > Thank you for the provided article. This article covers the main
> > approach
> > to integrating zmq fd into event loops more precisely than
> > stackoverflow
> > threads I've linked to my question. But it seems that there is still
> > no
> > answer to my question there, because my problem is in the very
> > beginning of
> > an integration process - I never get my IO_IN callback triggered :)
> > In other words, when I call `recv` method in a for loop directly, I
> > got
> > data, but when I connect zmq file descriptor to glib event loop to
> > listen
> > to IO_IN conditions, lambda function that handles such events is
> > never
> > called.
> > I've also tried connecting to other conditions than IO_IN, actually
> > to all
> > others (IO_ERR, IO_PRI, etc), but the result was the same except with
> > IO_OUT. IO_OUT condition triggers the callback, but writing to fd is
> > not my
> > case, as I am using ZMQ_SUB socket which is only for read purpose.
> >
> > 2017-07-27 15:55 GMT+03:00 Luca Boccassi :
> >
> > > On Thu, 2017-07-27 at 15:02 +0300, Alexander Yanin wrote:
> > > > I am trying to integrate ZeroMQ into my Glib main event loop. As
> > > > I
> > > > have
> > > > seen on the official ZeroMQ FAQ and API reference and on some
> > > > stackoverflow
> > > > threads (zeromq glib main loop integration
> > > >  > > > p-in
> > > > tegration>
> > > > and How to use ZeroMQ in an GTK/QT/Clutter application?
> > > >  > > > -an-
> > > > gtk-qt-clutter-application>),
> > > > to do this I need to get ZeroMQ FD and then connect it to
> > > > existing
> > > > event
> > > > loop. But, unfortunately, In my case this does not work.
> > > >
> > > > here is the code:
> > > >
> > > > RefPtr zmq_in;
> > > > zmq::context_t context (1);
> > > > zmq::socket_t subscriber (context, ZMQ_SUB);
> > > >
> > > > subscriber.connect("tcp://localhost:5556");const char *filter =
> > > > "10001 ";
> > > > subscriber.setsockopt(ZMQ_SUBSCRIBE, filter, strlen (filter));
> > > > const auto read_zmq = [this, ](Glib::IOCondition c) ->
> > > > bool {
> > > > std::cout << " Received message on zmq!" << std::endl;
> > > > int zipcode, temperature, relhumidity;
> > > > zmq::message_t update;
> > > > subscriber.recv();
> > > > std::istringstream iss(static_cast(update.data()));
> > > > iss >> zipcode >> temperature >> relhumidity;
> > > > std::cout << "Zipcode: " << zipcode << " Temperature: " <<
> > > > temperature
> > > >   << "Humidity: " << relhumidity;
> > > > return true;};
> > > > for (int i = 0; i < 10 ; i++) {
> > > > int zipcode, temperature, relhumidity;
> > > > zmq::message_t update;
> > > > subscriber.recv();
> > > > std::istringstream iss(static_cast(update.data()));
> > > > iss >> zipcode >> temperature >> relhumidity;
> > > > std::cout << "Zipcode: " << zipcode << "  Temperature: " <<
> > > > temperature
> > > >   << "  Humidity: " << relhumidity << std::endl;}
> > > > int fd = subscriber.getsockopt(ZMQ_FD);
> > > > zmq_in = IOChannel::create_from_fd(fd);
> > > > Glib::signal_io().connect(read_zmq, zmq_in, Glib::IO_IN);
> > > >
> > > > What really happens when the code is executed: 10 messages are
> > > > successfully
> > > > received from Publisher (another process) in the for loop, but
> > > > when
> > > > it
> > > > comes to receiving messages from the Glib main event loop, my c++
> > > > lambda is
> > > > never called :(
> > > >
> > > > Here is the Publisher code in C almost completely taken from
> > > > ZeroMQ
> > > > Guide:
> > > >
> > > > #include #include #include #include
> > > > #include #include 
> > > > int main (void){
> > > > //  Prepare our context and publisher
> > > > void *context = zmq_ctx_new ();
> > > > void *publisher = zmq_socket (context, ZMQ_PUB);
> > > > int rc = zmq_bind (publisher, "tcp://*:5556");
> > > > assert (rc == 

Re: [zeromq-dev] inproc message delivery

[Thomas Rodgers]

That seems about right. As noted by other replies, inproc is still waiting
on an event fd to signal, as is the case with IPC queues. Also as noted by
others there are some newer socket types (caveat I haven't used them) that
use different sync primitives (mutex) which *might* yield better in process
throughout. The mutex impl will spin a bit in CAS loop (with back off)
before resorting to a system call to wait on a contended lock.

On Thu, Apr 6, 2017 at 7:49 AM Marlborough, Rick <rmarlboro...@aaccorp.com>
wrote:

> Designation: Non-Export Controlled Content
>
> Tom;
>
>   Thanx for your response. We have done most of our testing with 1000 byte
> messages. The 2 endpoint types are ZMQ_REQ and ZMQ_REP. Our loop is a
> simple tight loop,  no sleeps. And yes you are correct, I meant to say
> “inproc should be blazing fast compared to ipc”.
>
>
>
> Rick
>
>
>
> *From:* zeromq-dev [mailto:zeromq-dev-boun...@lists.zeromq.org] *On
> Behalf Of *Thomas Rodgers
> *Sent:* Wednesday, April 05, 2017 5:44 PM
> *To:* ZeroMQ development list
> *Subject:* Re: [zeromq-dev] inproc message delivery
>
>
>
> I assume you meant to say 'inproc' would be blazing fast compared to 'ipc'?
>
>
>
> What message size(s) have you tried?
>
>
>
> I'm not convinced this is a reasonable expectation, particularly with
> smallish messages. IPC transport is going to involve a few more kernel
> calls but at the end of the day, it's still memory -> memory, and the
> improc socket type still has most of the zmq socket machinery to traverse.
>
>
>
> Tom.
>
>
>
> On Wed, Apr 5, 2017 at 4:34 PM Marlborough, Rick <rmarlboro...@aaccorp.com>
> wrote:
>
> Designation: Non-Export Controlled Content
>
> Folks;
>
> We are testing message delivery between 2 zmq sockets. We have done
> testing over the network between 2 nodes, on a single node and within a
> single process. For the single process case we use inproc transport. When
> we examine the delivery times we find that single node ipc transport is
> better than network. Surprisingly, inproc transport performance is
> virtually indistinguishable from ipc transport. I would expect ipc to be
> blazing fast in comparison. For the record we are using ZeroMQ 4.2.2 on red
> hat 7 64 bit. What should I expect using ipc transport?
>
>
>
> Thanx
>
> Rick
>
> 3.1.1001
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.zeromq.org_mailman_listinfo_zeromq-2Ddev=DwMFaQ=L6cnQwNGJqqFwLSmuJQH9Q=0vkEC-wQCdHs6_7-T7j4hT5guWBPAv8lluqeyT5n0ww=mrX-hpGIcyNBaHRii9heQgffNpjktFjcAI_pw2ReYWU=P_r7t1SUk889jbfnBv0zqAJ-0htcg2B2eRy-hR6gF3s=>
>
> 3.1.1001
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] inproc message delivery

[Thomas Rodgers]

I assume you meant to say 'inproc' would be blazing fast compared to 'ipc'?

What message size(s) have you tried?

I'm not convinced this is a reasonable expectation, particularly with
smallish messages. IPC transport is going to involve a few more kernel
calls but at the end of the day, it's still memory -> memory, and the
improc socket type still has most of the zmq socket machinery to traverse.

Tom.

On Wed, Apr 5, 2017 at 4:34 PM Marlborough, Rick 
wrote:

> Designation: Non-Export Controlled Content
>
> Folks;
>
> We are testing message delivery between 2 zmq sockets. We have done
> testing over the network between 2 nodes, on a single node and within a
> single process. For the single process case we use inproc transport. When
> we examine the delivery times we find that single node ipc transport is
> better than network. Surprisingly, inproc transport performance is
> virtually indistinguishable from ipc transport. I would expect ipc to be
> blazing fast in comparison. For the record we are using ZeroMQ 4.2.2 on red
> hat 7 64 bit. What should I expect using ipc transport?
>
>
>
> Thanx
>
> Rick
>
> 3.1.1001
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Thomas Rodgers]

I will have some time most likely the week of Nov6 (off for a week of C++
Committee 'fun') to test different message size alternatives. I'll follow
up with my results here for consideration the next time we are inclined to
break the ABI compatibility :)

On Sunday, October 16, 2016, Brian Knox  wrote:

> A new stable version would definitely help me in my quest to get ZeroMQ
> support enabled by default in rsyslog in distros.
>
> On Sun, Oct 16, 2016 at 2:40 PM Doron Somech  wrote:
>
>> I say lets bump.
>>
>> On Oct 15, 2016 20:32, "Luca Boccassi"  wrote:
>>
>>> As Thomas said, false sharing would be a real issue with 96.
>>>
>>> So given a release is long due, at this point I'd say to drop this for
>>> the moment.
>>>
>>> What do we do for the change to union for zmq_msg_t? Bump ABI version or
>>> not?
>>>
>>> On Thu, 2016-10-06 at 09:53 +0300, Doron Somech wrote:
>>> > No new socket type, I worked at the time on binary message type, might
>>> > complete it sometime, but it is not urgent.
>>> >
>>> > If there is a lot of performance penalty we can give it up, I will
>>> > find another solution for the Radio-Dish.
>>> >
>>> > What about 96 bytes? same penalty?
>>> >
>>> > Regarding the binding, I'm not sure.
>>> >
>>> > On Sat, Oct 1, 2016 at 9:14 PM, Luca Boccassi 
>>> wrote:
>>> > > On Tue, 2016-09-27 at 09:41 +0300, Doron Somech wrote:
>>> > >> Sorry for the late response, increasing the msg_t structure will be
>>> > >> great, however this will require changing a lot of binding.
>>> > >
>>> > > I think I remember we need it for the new socket types, is that
>>> correct?
>>> > >
>>> > > There is a large performance penalty (intuitively due to not fitting
>>> > > into a single cache line anymore, but haven't ran perf/cachegrind),
>>> and
>>> > > the throughput with vsm type messages goes down by 4% (min) and 20%
>>> > > (max) for TCP, and 36% (min) 38 (max) for inproc, which is quite a
>>> lot,
>>> > > so we need to be sure it's worth it.
>>> > >
>>> > > Regarding the bindings, after a quick search on the Github org, I
>>> could
>>> > > only see:
>>> > >
>>> > > https://github.com/zeromq/lzmq/blob/master/src/lua/lzmq/
>>> ffi/api.lua#L144
>>> > > https://github.com/zeromq/clrzmq4/blob/master/lib/zmq.cs#L28
>>> > > https://github.com/zeromq/pyczmq/blob/master/pyczmq/zmq.py#L177
>>> > >
>>> > > Other bindings just import zmq.h. Did I miss any?
>>> > >
>>> > >> Sorry for disappearing, baby and full time job is a lot :-),
>>> hopefully
>>> > >> I'm back...
>>> > >
>>> > > No worries, perfectly understandable :-)
>>> > >
>>> > >> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi <
>>> luca.bocca...@gmail.com> wrote:
>>> > >> > Sorry, I meant if we go with (1), not (2), we might bump the size
>>> as
>>> > >> > well, since we are already doing another ABI-breaking change.
>>> > >> >
>>> > >> > I agree on the solution as well.
>>> > >> >
>>> > >> > On Mon, 2016-08-29 at 17:12 +0200, Pieter Hintjens wrote:
>>> > >> >> I'm confused between the (1) and (2) choices, and can't see where
>>> > >> >> bumping the message size fits.
>>> > >> >>
>>> > >> >> Nonetheless, I think bumping the size, fixing the alignment
>>> issues,
>>> > >> >> and bumping the ABI version is the best solution here.
>>> > >> >>
>>> > >> >> On Fri, Aug 26, 2016 at 12:33 PM, Luca Boccassi <
>>> luca.bocca...@gmail.com> wrote:
>>> > >> >> > I've given some more thoughts and testing to the alignment
>>> issue. I can
>>> > >> >> > reproduce the problem by enabling alignment checks on x86 too.
>>> > >> >> >
>>> > >> >> > But most importantly, I think we cannot get away from bumping
>>> the ABI
>>> > >> >> > with this fix, however we rearrange it, simply because
>>> applications need
>>> > >> >> > to be rebuilt against the new header to be fixed. A simple
>>> rebuild of
>>> > >> >> > the libzmq.so is not enough. And the way to do this is to bump
>>> the ABI
>>> > >> >> > so that distros can schedule transitions and rebuilds and so
>>> on.
>>> > >> >> >
>>> > >> >> > So the choice list is now restricted to:
>>> > >> >> >
>>> > >> >> > 1) Bump ABI
>>> > >> >> > 2) Revert the fix and leave everything broken on sparc64 and
>>> some
>>> > >> >> > aarch64 (rpi3 seems not to be affected, must depend on the SoC
>>> flavour)
>>> > >> >> >
>>> > >> >> > If we go with 2, we might as well get 2 birds with one stone
>>> and bump
>>> > >> >> > the zmq_msg_t size to 128 as we have talked about in the past.
>>> > >> >> >
>>> > >> >> > Doron, this would help with the new UDP based socket types
>>> right?
>>> > >> >> >
>>> > >> >> > Pros of bumping msg size:
>>> > >> >> >
>>> > >> >> > - we can get rid of the malloc() in the lmsg type case as all
>>> the data
>>> > >> >> > will fit
>>> > >> >> >
>>> > >> >> > Cons:
>>> > >> >> >
>>> > >> >> > - for the vsm/cmsg type cases (for most architectures anyway)
>>> it won't
>>> > >> >> > fit anymore into a single cacheline
>>> > >> >> >

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Thomas Rodgers]

>
> Looking forward to seeing the benchmarks on that idea!


The most direct way to do so (and most relevant to libzmq, rather than my
toy implementation over Boost Asio) would be to make the change in the
existing zmq code base and benchmark it with a few sizes. I will make some
time to do that over the next week or so.

On Fri, Oct 7, 2016 at 7:28 AM, Manuel Amador (Rudd-O) <rud...@rudd-o.com>
wrote:

> On 10/06/2016 02:03 PM, Thomas Rodgers wrote:
> >
> > What about 96 bytes? same penalty?
> >
> >
> > If you are going to bump the size to > 64 bytes (x86 cache line size),
> > it likely should be rounded up to to 128 bytes, so as to eliminate any
> > potential for false sharing on architectures with 64 byte cache lines.
> >
> > Having said that, I've been playing with an experimental C++
> > implementation of ZMTP using much larger fixed message struct sizes of
> > ~512 bytes. It's nothing more than a toy implementation at this point
> > and I don't have any real perf numbers, but my reasoning for the
> > larger message size is that ZMTP has explicit optimization for small
> > messages of < 256 bytes. A size > 256 bytes accommodates all small
> > ZMTP messages without an extra allocation and indirection and the
> > reference counting overhead of the large message type (all potentially
> > much more expensive operations than the cost of simply being larger
> > than a cache line), along with message metadata, and likely a decent
> > fraction of "large" ZMTP messages.
>
> Looking forward to seeing the benchmarks on that idea!
>
>
> --
> Rudd-O
> http://rudd-o.com/
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Thomas Rodgers]

>
> What about 96 bytes? same penalty?


If you are going to bump the size to > 64 bytes (x86 cache line size), it
likely should be rounded up to to 128 bytes, so as to eliminate any
potential for false sharing on architectures with 64 byte cache lines.

Having said that, I've been playing with an experimental C++ implementation
of ZMTP using much larger fixed message struct sizes of ~512 bytes. It's
nothing more than a toy implementation at this point and I don't have any
real perf numbers, but my reasoning for the larger message size is that
ZMTP has explicit optimization for small messages of < 256 bytes. A size >
256 bytes accommodates all small ZMTP messages without an extra allocation
and indirection and the reference counting overhead of the large message
type (all potentially much more expensive operations than the cost of
simply being larger than a cache line), along with message metadata, and
likely a decent fraction of "large" ZMTP messages.



On Thu, Oct 6, 2016 at 1:53 AM, Doron Somech  wrote:

> No new socket type, I worked at the time on binary message type, might
> complete it sometime, but it is not urgent.
>
> If there is a lot of performance penalty we can give it up, I will
> find another solution for the Radio-Dish.
>
> What about 96 bytes? same penalty?
>
> Regarding the binding, I'm not sure.
>
> On Sat, Oct 1, 2016 at 9:14 PM, Luca Boccassi 
> wrote:
> > On Tue, 2016-09-27 at 09:41 +0300, Doron Somech wrote:
> >> Sorry for the late response, increasing the msg_t structure will be
> >> great, however this will require changing a lot of binding.
> >
> > I think I remember we need it for the new socket types, is that correct?
> >
> > There is a large performance penalty (intuitively due to not fitting
> > into a single cache line anymore, but haven't ran perf/cachegrind), and
> > the throughput with vsm type messages goes down by 4% (min) and 20%
> > (max) for TCP, and 36% (min) 38 (max) for inproc, which is quite a lot,
> > so we need to be sure it's worth it.
> >
> > Regarding the bindings, after a quick search on the Github org, I could
> > only see:
> >
> > https://github.com/zeromq/lzmq/blob/master/src/lua/lzmq/ffi/api.lua#L144
> > https://github.com/zeromq/clrzmq4/blob/master/lib/zmq.cs#L28
> > https://github.com/zeromq/pyczmq/blob/master/pyczmq/zmq.py#L177
> >
> > Other bindings just import zmq.h. Did I miss any?
> >
> >> Sorry for disappearing, baby and full time job is a lot :-), hopefully
> >> I'm back...
> >
> > No worries, perfectly understandable :-)
> >
> >> On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi 
> wrote:
> >> > Sorry, I meant if we go with (1), not (2), we might bump the size as
> >> > well, since we are already doing another ABI-breaking change.
> >> >
> >> > I agree on the solution as well.
> >> >
> >> > On Mon, 2016-08-29 at 17:12 +0200, Pieter Hintjens wrote:
> >> >> I'm confused between the (1) and (2) choices, and can't see where
> >> >> bumping the message size fits.
> >> >>
> >> >> Nonetheless, I think bumping the size, fixing the alignment issues,
> >> >> and bumping the ABI version is the best solution here.
> >> >>
> >> >> On Fri, Aug 26, 2016 at 12:33 PM, Luca Boccassi <
> luca.bocca...@gmail.com> wrote:
> >> >> > I've given some more thoughts and testing to the alignment issue.
> I can
> >> >> > reproduce the problem by enabling alignment checks on x86 too.
> >> >> >
> >> >> > But most importantly, I think we cannot get away from bumping the
> ABI
> >> >> > with this fix, however we rearrange it, simply because
> applications need
> >> >> > to be rebuilt against the new header to be fixed. A simple rebuild
> of
> >> >> > the libzmq.so is not enough. And the way to do this is to bump the
> ABI
> >> >> > so that distros can schedule transitions and rebuilds and so on.
> >> >> >
> >> >> > So the choice list is now restricted to:
> >> >> >
> >> >> > 1) Bump ABI
> >> >> > 2) Revert the fix and leave everything broken on sparc64 and some
> >> >> > aarch64 (rpi3 seems not to be affected, must depend on the SoC
> flavour)
> >> >> >
> >> >> > If we go with 2, we might as well get 2 birds with one stone and
> bump
> >> >> > the zmq_msg_t size to 128 as we have talked about in the past.
> >> >> >
> >> >> > Doron, this would help with the new UDP based socket types right?
> >> >> >
> >> >> > Pros of bumping msg size:
> >> >> >
> >> >> > - we can get rid of the malloc() in the lmsg type case as all the
> data
> >> >> > will fit
> >> >> >
> >> >> > Cons:
> >> >> >
> >> >> > - for the vsm/cmsg type cases (for most architectures anyway) it
> won't
> >> >> > fit anymore into a single cacheline
> >> >> >
> >> >> > Given all this, I'd say we should go for it.
> >> >> >
> >> >> > Opinions?
> >> >> >
> >> >> > On Sat, 2016-08-13 at 16:59 +0100, Luca Boccassi wrote:
> >> >> >> Hello,
> >> >> >>
> >> >> >> Trying to give some thoughts again on the libzmq 4.2 release. It's
> >> >> >> really long 

Re: [zeromq-dev] Why no shared-memory IPC?

[Thomas Rodgers]

Well, if you are allergic to Boost (or allergic to substantially
reimplementing what Boost Interprocess gives you), yes ;-

On Sat, Jul 11, 2015 at 3:22 AM, Pieter Hintjens p...@imatix.com wrote:

 Ah, so you're saying it's almost impossible :)

 On Sat, Jul 11, 2015 at 8:53 AM, Michael Haberler mai...@mah.priv.at
 wrote:
 
  Am 09.07.2015 um 21:09 schrieb Thomas Johnson 
 thomas.j.john...@gmail.com:
 
  My understanding is that on Linux, inproc is implemented using shared
 memory and ipc is implemented using named pipes. Is there a reason why
 inter-process communication via shared memory is not supported?
 
  I touched on this before:
 http://lists.zeromq.org/pipermail/zeromq-dev/2014-February/025128.html
 
  the eventfd notification across process boundaries works fine, but
 allocation and processing of messages (and pointers for that matter) in
 shared memory is likely hard because one cannot assume the arena be mapped
 at the same address in all participating processes; a lot of assumptions on
 pointers go out of the window if you go down that route, and overhead
 increases. It's more doable in C++ - boost.interprocesses addresses the
 issue but pretty hard in C.
 
  -m
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] missing messages on 40GbE network

[Thomas Rodgers]

Futzing about with system tap is what lead us to this. In our case it looks
like the kernel flush process is what is holding the lock when we see
this happen.

On Tue, Jul 7, 2015 at 11:22 AM, Marko Vendelin mar...@sysbio.ioc.ee
wrote:

 The filesystem(s) (31 disks mounted separately) are XFS. I tried ext4 as
 well, no big difference. But failure to acquire lock maybe something to
 look into. System, when stalled, does not have any cpu load and seem to
 idle mainly. How did you find that in your case this function was
 responsible?

 Marko

 On Tue, Jul 7, 2015 at 6:36 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:
  Is the filesystem ext4? We have seen issues with high rates of smallish
  writes to ext4 (it seems related to failing to acquire a lock in
  http://lxr.free-electrons.com/source/fs/ext4/extents.c?v=2.6.32#L3228).
 
  Using XFS seems to improve the situation for us.
 
  On Tue, Jul 7, 2015 at 2:16 AM, Marko Vendelin mar...@sysbio.ioc.ee
 wrote:
 
  Hi Peter,
 
  thank you for the pointers. Its seems now that there is some problem
  with the disk I/O, as suspected first. Namely, when system starts to
  'crawl', I can fire up new clients that don't write anything and these
  clients are doing absolutely fine (recording high rates). New clients
  with disk i/o crawl immediately.
 
  I'll look into it and would try to isolate the issue further.
 
  REP-REQ: No, I was using multiple requests in PAIR sockets, as you
  advised earlier.
 
  NORM: When things work, TCP is fine. As far as I know a lot is
  processed on the cards internally and I can get to the rates that are
  as large as needed.
 
  I'll let the list know if the problem is in disk I/O and what was the
  cause of it.
 
  Best wishes,
 
  Marko
 
 
  On Mon, Jul 6, 2015 at 11:30 PM, Peter Krey k...@ripple.com wrote:
   You may want to try switching to a UDP based protocol like NORM on
 zmq.
   This
   will let you achieve higher throughput as there will be no TCP packet
   handshakes.
  
   You can also try installing multiple NIC cards on your computer and
 bind
   them together into one device for higher throughput if you think the
   cards
   devices buffers are being overrun.
  
   On Mon, Jul 6, 2015 at 1:25 PM, Peter Krey k...@ripple.com wrote:
  
   You are not using REQ-REP properly; a REQ-REP socket will not accept
   two
   REQ messages in a row; it needs a REP before it will proceed
 otherwise
   it
   will block.
  
   I highly advise you using PAIR type for all sockets in your
 application
   and no REQ-REP sockets at all, especially given the throughput
 required
   in
   your application.
  
   On Sun, Jul 5, 2015 at 9:58 AM, Marko Vendelin mar...@sysbio.ioc.ee
 
   wrote:
  
   I did reprogram using pair sockets, one per each client. They were
   still
   using request reply pattern and when request was not replied to, the
   client
   repeated the request. Unfortunately, the similar behaviour was
   observed:
   initial fast rate reduced and never recovered.
  
   I'm wondering is it possible to get error codes out of zeromq to see
   where the problem is?
  
   Best wishes
  
   Marko
  
   On Jul 4, 2015 12:04 AM, Marko Vendelin marko.vende...@gmail.com
 
   wrote:
  
   Is there any way I could check for automatic drop of messages by
   zeromq? I could recompile the library with some debug settings if
   needed, but this information would be very valuable.
  
   In this case I would expect to have the same in nanomsg as well and
   in
   the beginning of the test with ZeroMQ. We should have disk i/o
 faster
   than the network. Since the dropoff happens at ~10minutes when
 using
   zeromq, RAM would not be able to cache the data either (at that
 time
   I
   have transferred already ~2TB in 64GB RAM machines).
  
   Use of REQ/REP allows me to spread the load among all disks
   automatically. Since disk writers are one per HDD and after
 receiving
   each dataset write it on disk, the load per disk is proportional to
   its speed. The rates I am getting in the beginning with ZMQ (first
   ~10
   min, ~30-36Gb/s) are above our requirements and would fit the
   application perfectly. If I could only sustain it as long as the
 disk
   space allows.
  
   Re PAIR: I was thinking about giving PAIR a try. Would need to
   reprogram a bit, but its possible.
  
   Best wishes,
  
   Marko
  
  
   On Fri, Jul 3, 2015 at 10:52 PM, Peter Krey peterjk...@gmail.com
   wrote:
You may be sending messages faster than you can receive them and
write
them
to disk, overflowing zeromq message send buffer causing zeromq to
automatically discard some messages. This is expected behavior.
   
Also do not use socket type request reply, use pair. This will
 not
require
your app to recv and reply before sending the next image; your
 app
can
send
async.
   
On Wednesday, July 1, 2015, Marko Vendelin mar...@sysbio.ioc.ee
 
wrote:
   
Dear ØMQ developers:
   
Synopsis: I am observing

Re: [zeromq-dev] missing messages on 40GbE network

[Thomas Rodgers]

Is the filesystem ext4? We have seen issues with high rates of smallish
writes to ext4 (it seems related to failing to acquire a lock in
http://lxr.free-electrons.com/source/fs/ext4/extents.c?v=2.6.32#L3228).

Using XFS seems to improve the situation for us.

On Tue, Jul 7, 2015 at 2:16 AM, Marko Vendelin mar...@sysbio.ioc.ee wrote:

 Hi Peter,

 thank you for the pointers. Its seems now that there is some problem
 with the disk I/O, as suspected first. Namely, when system starts to
 'crawl', I can fire up new clients that don't write anything and these
 clients are doing absolutely fine (recording high rates). New clients
 with disk i/o crawl immediately.

 I'll look into it and would try to isolate the issue further.

 REP-REQ: No, I was using multiple requests in PAIR sockets, as you
 advised earlier.

 NORM: When things work, TCP is fine. As far as I know a lot is
 processed on the cards internally and I can get to the rates that are
 as large as needed.

 I'll let the list know if the problem is in disk I/O and what was the
 cause of it.

 Best wishes,

 Marko


 On Mon, Jul 6, 2015 at 11:30 PM, Peter Krey k...@ripple.com wrote:
  You may want to try switching to a UDP based protocol like NORM on zmq.
 This
  will let you achieve higher throughput as there will be no TCP packet
  handshakes.
 
  You can also try installing multiple NIC cards on your computer and bind
  them together into one device for higher throughput if you think the
 cards
  devices buffers are being overrun.
 
  On Mon, Jul 6, 2015 at 1:25 PM, Peter Krey k...@ripple.com wrote:
 
  You are not using REQ-REP properly; a REQ-REP socket will not accept two
  REQ messages in a row; it needs a REP before it will proceed otherwise
 it
  will block.
 
  I highly advise you using PAIR type for all sockets in your application
  and no REQ-REP sockets at all, especially given the throughput required
 in
  your application.
 
  On Sun, Jul 5, 2015 at 9:58 AM, Marko Vendelin mar...@sysbio.ioc.ee
  wrote:
 
  I did reprogram using pair sockets, one per each client. They were
 still
  using request reply pattern and when request was not replied to, the
 client
  repeated the request. Unfortunately, the similar behaviour was
 observed:
  initial fast rate reduced and never recovered.
 
  I'm wondering is it possible to get error codes out of zeromq to see
  where the problem is?
 
  Best wishes
 
  Marko
 
  On Jul 4, 2015 12:04 AM, Marko Vendelin marko.vende...@gmail.com
  wrote:
 
  Is there any way I could check for automatic drop of messages by
  zeromq? I could recompile the library with some debug settings if
  needed, but this information would be very valuable.
 
  In this case I would expect to have the same in nanomsg as well and in
  the beginning of the test with ZeroMQ. We should have disk i/o faster
  than the network. Since the dropoff happens at ~10minutes when using
  zeromq, RAM would not be able to cache the data either (at that time I
  have transferred already ~2TB in 64GB RAM machines).
 
  Use of REQ/REP allows me to spread the load among all disks
  automatically. Since disk writers are one per HDD and after receiving
  each dataset write it on disk, the load per disk is proportional to
  its speed. The rates I am getting in the beginning with ZMQ (first ~10
  min, ~30-36Gb/s) are above our requirements and would fit the
  application perfectly. If I could only sustain it as long as the disk
  space allows.
 
  Re PAIR: I was thinking about giving PAIR a try. Would need to
  reprogram a bit, but its possible.
 
  Best wishes,
 
  Marko
 
 
  On Fri, Jul 3, 2015 at 10:52 PM, Peter Krey peterjk...@gmail.com
  wrote:
   You may be sending messages faster than you can receive them and
 write
   them
   to disk, overflowing zeromq message send buffer causing zeromq to
   automatically discard some messages. This is expected behavior.
  
   Also do not use socket type request reply, use pair. This will not
   require
   your app to recv and reply before sending the next image; your app
 can
   send
   async.
  
   On Wednesday, July 1, 2015, Marko Vendelin mar...@sysbio.ioc.ee
   wrote:
  
   Dear ØMQ developers:
  
   Synopsis: I am observing a strange interaction between storing
   datastream on harddisks and a loss of ZeroMQ messages. It seems
 that
   in my use case, when messages are larger than 2MB, some of them are
   randomly dropped.
  
   Full story:
  
   I need to pump images acquired by fast scientific cameras into the
   files with the rates approaching 25Gb/s. For that, images are
   acquired
   in one server and transferred into the harddisk array using 40Gb/s
   network. Since Linux-based solutions using iSCSI were not working
   very
   well (maybe need to optimize more) and plain network applications
   could use the full bandwidth, I decided to use RAID-0 inspired
   approach: make filesystem on each of 32 harddisks separately, run
   small slave programs one per filesystem and let the slaves ask the
   

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

Glad it worked for you, though I think you really do need to make the array
type char or unsigned char to not run afoul (though for 99% of the hardware
in the world it makes no difference) of section 3.9.2 of the standard -

For any object (other than a base-class subobject) of trivially copyable
 type T, whether or not the object holds a valid value of type T, the
 underlying bytes (1.7) making up the object can be copied into an array of
 char or unsigned char. 40 If the content of the array of char or unsigned
 char is copied back into the object, the object shall subsequently hold its
 original value


In trying to follow up on the strict legality of the technique and the
strict aliasing warning issued by GCC, one of the implementers of GCC's
libstdc++ remarked -

 The double static_cast might as well just be a reinterpret_cast, which
  is equivalent but less typing.
 
return *reinterpret_castatomic_counter_t*(m.lmsg.ctr_stg);
 
 
  I agree that's what *should* happen with reinterpret_cast, but with
 GCC4.9.2
  and -Wall -Wextra -Werror this results in -
 
  'error: dereferencing type-punned pointer will break strict-aliasing
 rules'

 Hmm, so it does.

 Using the pointer returned by the placement-new expression doesn't get
 a warning, even though it's doing the same thing (saying I know this
 looks like chars, but I've put an object here). I wonder if that's
 because the placement-new just obscures the code (like the double
 static_cast) or if the compiler gives ::new some magic powers.



And if that's an aliasing violation then std::aligned_storage is

impossible to use correctly.




On Tue, Jun 2, 2015 at 4:29 PM, Jens Auer jens.a...@betaversion.net wrote:

 Hi Thomas,



 I changed my patch to use a

 union {

 zmq::atomic_counter_t aligner;

 uint8_t counter[ sizeof(zmq::atomic_counter_t) ];

 }

 to have a storage which is hopefully aligned. I think this this is
 probably ok, because the values before that in the struct are all pointers
 or integer values which should have a proper alignment, and the
 atomic_counter_t follows. ‘ve also added the double static_cast in an
 accessor function and it compiles without C++11and seems to work.



 Thanks for the suggestion,

   Jens





 *Von:* zeromq-dev-boun...@lists.zeromq.org [mailto:
 zeromq-dev-boun...@lists.zeromq.org] *Im Auftrag von *Thomas Rodgers
 *Gesendet:* Dienstag, 2. Juni 2015 19:59
 *An:* Jens Auer; ZeroMQ development list

 *Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive



 FWIW, I made a local change to msg_t::content_t to use a type erased
 zmq::atomic_counter_t and it compiles (without relaxing warnings) and
 passes all tests.



 On Tue, Jun 2, 2015 at 12:14 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 Current vector implementations (AFAIK) don't do small object
 optimizations, but I have it on good authority (the author sits next to me
 at work) there is a proposal coming for such a vector, and it would face
 the exact same problem. std::vector does use a dynamically allocated array,
 but not of type T, otherwise reserve() would unimplementable. Is the point
 that a void* that comes via malloc is somehow different than a member array
 in terms of type punning? This may well be strictly true (see
 aforementioned malloc standards weasel wording comment), but there are
 many many libraries which do small object optimizations via the double
 static_cast approach that would break if it didn't work (never mind whether
 it is legal). The standard already includes types that do this sort of
 punning (std::function, std::aligned_storage, proposed std::optional,
 proposed std::variant).



 In any event, I've dropped an email to a couple of fellow C++ standards
 committee members (including a Clang developer) to see what their thoughts
 on this are.







 On Tue, Jun 2, 2015 at 11:53 AM, Jens Auer jens.a...@betaversion.net
 wrote:

 I always thought that vector uses a dynamically allocated array and not a
 char []. That would give us a char* which we can savely cast into another
 pointer. I don't have the source available, but if it uses small object
 optimization, it has to use a static array backend. I will take a look at
 the vector source code.



 Thanks,

  Jens




  Ursprüngliche Nachricht 
 Von: Thomas Rodgers rodg...@twrodgers.com
 Datum: 02.06.2015 18:37 (GMT+01:00)
 An: ZeroMQ development list zeromq-dev@lists.zeromq.org

 Betreff: Re: [zeromq-dev] (almost) zero-copy message receive

 If it were completely broken, then how could vector work (it is the
 current poster child for type erased aligned storage)? std::aligned_storage
 (and boost::aligned_storage) also do type erasure through a char backing
 array. It might well be strictly illegal relative to standards wording
 (there was some discussion along these lines at the fall Standards
 meeting), but it would essentially preclude any sort of placement new
 except the via the magic weasel words that allow malloc.



 On Tue, Jun 2

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

FWIW, I made a local change to msg_t::content_t to use a type erased
zmq::atomic_counter_t and it compiles (without relaxing warnings) and
passes all tests.

On Tue, Jun 2, 2015 at 12:14 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:

 Current vector implementations (AFAIK) don't do small object
 optimizations, but I have it on good authority (the author sits next to me
 at work) there is a proposal coming for such a vector, and it would face
 the exact same problem. std::vector does use a dynamically allocated array,
 but not of type T, otherwise reserve() would unimplementable. Is the point
 that a void* that comes via malloc is somehow different than a member array
 in terms of type punning? This may well be strictly true (see
 aforementioned malloc standards weasel wording comment), but there are
 many many libraries which do small object optimizations via the double
 static_cast approach that would break if it didn't work (never mind whether
 it is legal). The standard already includes types that do this sort of
 punning (std::function, std::aligned_storage, proposed std::optional,
 proposed std::variant).

 In any event, I've dropped an email to a couple of fellow C++ standards
 committee members (including a Clang developer) to see what their thoughts
 on this are.



 On Tue, Jun 2, 2015 at 11:53 AM, Jens Auer jens.a...@betaversion.net
 wrote:

 I always thought that vector uses a dynamically allocated array and not a
 char []. That would give us a char* which we can savely cast into another
 pointer. I don't have the source available, but if it uses small object
 optimization, it has to use a static array backend. I will take a look at
 the vector source code.

 Thanks,
  Jens



  Ursprüngliche Nachricht 
 Von: Thomas Rodgers rodg...@twrodgers.com
 Datum: 02.06.2015 18:37 (GMT+01:00)
 An: ZeroMQ development list zeromq-dev@lists.zeromq.org
 Betreff: Re: [zeromq-dev] (almost) zero-copy message receive


 If it were completely broken, then how could vector work (it is the
 current poster child for type erased aligned storage)? std::aligned_storage
 (and boost::aligned_storage) also do type erasure through a char backing
 array. It might well be strictly illegal relative to standards wording
 (there was some discussion along these lines at the fall Standards
 meeting), but it would essentially preclude any sort of placement new
 except the via the magic weasel words that allow malloc.

 On Tue, Jun 2, 2015 at 11:30 AM, Auer, Jens jens.a...@cgi.com wrote:

  Yes, this doesn't change anything because it only depends on the
 existence of two pointers of different type pointing to the same address.
 There is an exception for char*, but here we would have a char array and an
 atomic_counter_t pointer pointing to it. This is illegal.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging
 to CGI Group Inc. and its affiliates may be contained in this message. If
 you are not a recipient indicated or intended in this message (or
 responsible for delivery of this message to such person), or you think for
 any reason that this message may have been addressed to you in error, you
 may not use or copy or deliver this message to anyone else. In such case,
 you should destroy this message and are asked to notify the sender by reply
 e-mail.
   --
 *Von:* zeromq-dev-boun...@lists.zeromq.org [
 zeromq-dev-boun...@lists.zeromq.org] im Auftrag von Thomas Rodgers [
 rodg...@twrodgers.com]
 *Gesendet:* Dienstag, 2. Juni 2015 18:10

 *An:* ZeroMQ development list
 *Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive

   with reinterpret_cast?

 On Tue, Jun 2, 2015 at 10:55 AM, Auer, Jens jens.a...@cgi.com wrote:

  I already tried this, but then the compiler complaint about a
 violation of the strict alias rules and the code doesn't compile anymore.
 The problem is that I access something of type uint8_t[] with a pointer of
 type atomic_counter_t.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging
 to CGI Group Inc. and its affiliates may be contained in this message. If
 you are not a recipient indicated or intended in this message (or
 responsible for delivery of this message to such person), or you think for
 any reason that this message may have

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

A better chart of compiler conformance is probably here -

http://en.cppreference.com/w/cpp/compiler_support

I don't know that there's been a flamewar around this topic, but
switching to -std=c++11 has been discussed recently in the context of
implementing thread safe sockets. IIRC the consensus at the time was to
stick with 98/03 conforming code.

In my experience, supporting C++11, opens opens up a bit of a minefield of
portability gotchas. For https://github.com/zeromq/azmq I can generally
fall back on Boost to paper over these issues, but that's not a realistic
option with libzmq. So, while I get that *this* change wouldn't necessarily
run afoul of the current state of C++ conformance for MSVC, I am personally
a bit leary of the general prospects of switching to C++11 in libzmq
because the next change that assumes C++11 conformance might not be
supported by the range of compilers used to build libzmq.



On Tue, Jun 2, 2015 at 8:44 AM, Auer, Jens jens.a...@cgi.com wrote:

  Hi,

 I don't want to start a flame war on this because I know that there can be
 very good reasons to not rely on C++11. That's why I did not just send the
 patch, but wanted to discuss it first and see if there are any other ways
 to do this.
 The main issue is that I want to put an atomic_counter_t into a union in
 msg_t, which C++98/C++03 does not allow because it has constructors and
 non-public data members. So an obvious way to solve this would be to make
 atomic_counter_t a plain C struct with free function to create and modify
 it. I was hoping for other suggestions.

 For what it's worth, the change does not need a fully compliant C++, but
 just standard layout and trivial types which are implemented in MSVC since
 2012.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.
   --
 *Von:* zeromq-dev-boun...@lists.zeromq.org [
 zeromq-dev-boun...@lists.zeromq.org] im Auftrag von Thomas Rodgers [
 rodg...@twrodgers.com]
 *Gesendet:* Dienstag, 2. Juni 2015 15:37

 *An:* ZeroMQ development list
 *Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive

Personally, I think that 4 years of C++11, this should not be an
 issues, but there may be platforms with old compilers which you want to
 support.


  4 years of C++11 *should* be enough, but wide-spread use of fully
 conforming compilers is still an issue, for instance -

  https://msdn.microsoft.com/en-us/library/hh567368.aspx

 On Tue, Jun 2, 2015 at 8:05 AM, Auer, Jens jens.a...@cgi.com wrote:

 Hi Pieter,

 the reason I wanted to ask first is because I had to switch on C++11 to
 make it work without changing atomic_counter_t. The reason is that I
 eliminated msg_t::content_t completely to save a mallic call  by adding the
 members in content_t to the msg_t class directly since there is now space
 enough. However, atomic_counter_t is not a POD and cannot be put into the
 union. For my proof-of-concept, switching on C++11 is fine, but I am not
 sure if that is ok for the main branch. Personally, I think that 4 years of
 C++11, this should not be an issues, but there may be platforms with old
 compilers which you want to support.

 The only alternative I came up with would be to make atomic_counter_t a
 classical C struct with free functions instead of a class. I don't like
 this very much.

 Best wishes,
   Jens

 --
 Jens Auer | CGI | Software-Engineer
 CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie
 unter de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.

 
 Von

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

 Personally, I think that 4 years of C++11, this should not be an issues,
 but there may be platforms with old compilers which you want to support.


4 years of C++11 *should* be enough, but wide-spread use of fully
conforming compilers is still an issue, for instance -

https://msdn.microsoft.com/en-us/library/hh567368.aspx

On Tue, Jun 2, 2015 at 8:05 AM, Auer, Jens jens.a...@cgi.com wrote:

 Hi Pieter,

 the reason I wanted to ask first is because I had to switch on C++11 to
 make it work without changing atomic_counter_t. The reason is that I
 eliminated msg_t::content_t completely to save a mallic call  by adding the
 members in content_t to the msg_t class directly since there is now space
 enough. However, atomic_counter_t is not a POD and cannot be put into the
 union. For my proof-of-concept, switching on C++11 is fine, but I am not
 sure if that is ok for the main branch. Personally, I think that 4 years of
 C++11, this should not be an issues, but there may be platforms with old
 compilers which you want to support.

 The only alternative I came up with would be to make atomic_counter_t a
 classical C struct with free functions instead of a class. I don't like
 this very much.

 Best wishes,
   Jens

 --
 Jens Auer | CGI | Software-Engineer
 CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie
 unter de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.

 
 Von: zeromq-dev-boun...@lists.zeromq.org [
 zeromq-dev-boun...@lists.zeromq.org]quot; im Auftrag von quot;Pieter
 Hintjens [p...@imatix.com]
 Gesendet: Dienstag, 2. Juni 2015 10:18
 An: ZeroMQ development list
 Betreff: Re: [zeromq-dev] (almost) zero-copy message receive

 Jens,

 Sounds great. Feel free to send such patches to libzmq master; please
 make sure they are as atomic as possible, each with a clear problem
 statement, each testable individually.

 -Pieter

 On Tue, Jun 2, 2015 at 10:13 AM, Arnaud Loonstra arn...@sphaero.org
 wrote:
  Although I'm not very familiar with zmq's internals this looks
  promising.
  Did you test if your implementation remains correct? ie. it doesn't
  introduce deadlocks or other race conditions?
 
  Rg,
 
  Arnaud
 
  On 2015-05-31 19:29, Jens Auer wrote:
  Hi,
 
  I did some performance analysis of  a program which receives data on
  a (SUB or
  PULL) socket, filters it for some criteria, extracts a value from the
  message
  and uses this as a subscription to forward the datato a PUB socket.
  As
  expected, most time is spent in memory allocations and memcpy
  operations, so I
  decided to check if there is an opportunity to  minimize these
  operations in
  the critical path. From my analysis, the path is as follows:
  1. stream_engine receives data from a socket into a static buffer of
  8192
  bytes
  2. decoder/v2_decoder implement a state machine which reads the flag
  and
  message size, create a new message and copy the data into the message
  data
  field
  3. When sending, stream_engine copies the flags field, message and
  message
  data into a static buffer and sends this buffer completely to the
  socket
 
  Memory allocations are done in v2_decoder when a new message is
  created, and
  deallocations are done when sending the message. Memcpy operations
  are done in
  decoder to copy
  - the flags byte into a temporary buffer
  - the message size into a temporary buffer
  - the message data into the dynamically allocated storage
 
  Since the allocations and memcpy are the dominating operations, I
  implemented
  a scheme where these operations are minimized. The main idea is to
  allocate
  the receive buffer of 8192 byte dynamically and use this as the data
  storage
  for zero-copy messages created with msg_t::init_data. This replaces n
  = 8192 /
  (m_size + 10) memory allocations with one allocation, and it gets rid
  of the
  same number of memcpy operations for the message data. I implemented
  this in a
  fork (https://github.com/jens-auer/libzmq/tree/zero_copy_receive).
  For
  testing, I ran the throughput test (message size 100, 10
  messages) locally
  and profiled for memory allocations and memcpy. The results are
  promising:
  - memory allocations reduced from 100,260 to 2,573
  - memcpy operations reduced from 301,227 to 202,449. This is expected
  because
  for every message, three memcpys are done, and the 

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

I am unaware of any list, it seems (to me at least) it's whatever people
have contributed support for.

As for a concrete suggestion. I am not sure this is any less ugly but...

libzmq goes out of it's way generally to avoid calling new() in many cases
(non-throwing failure on OOM presumably), preferring malloc() and placement
new instead, content_t was no exception. It did embed an explicit
atomic_counter_t and would placement new it, and explicitly call the
destructor when the lmsg was destroyed.

You could, instead declare the storage for atomic_counter_t as an array,
uint8_t ctr_storage[sizeof(atomic_counter_t)] and placement new/explicit
dtor as before, and then provide an accessor to return an atomic_counter_t
by returning *reinterpret_castatomic_counter_t*(ctr_storage[0]).

It doesn't change the size of the lmsg type, but it does remove one level
of indirection, and you have hidden the ugly bits behind an accessor method.

On Tue, Jun 2, 2015 at 9:40 AM, Auer, Jens jens.a...@cgi.com wrote:

  Hi Thomas,



 I did not want to say that you intended to start a flame war and you
 certainly did not. I know that things like these easily turn into flame
 wars, so I wanted to prevent that. All I wanted say was that I know that
 switching to C++11 may not be applicable so I want to discuss the patch
 first and search for an alternative to C++11. Do you have a suggestion for
 the issue with the non-POD atomic_counter_t? My experience is quite
 limited because I normally don’t write code which has to support older
 compilers.



 Just out of curiosity, do you know a definite list of compilers zeroMQ
 intends to supports? I only found the document
 http://zeromq.org/docs:builds, but this is quite outdated.



 Best wishes,

   Jens



 *--*

 *Dr. Jens Auer *| CGI | Software Engineer

 CGI Deutschland Ltd.  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany

 T: +49 6151 36860 154

 jens.a...@cgi.com

 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie
 unter de.cgi.com/pflichtangaben.



 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.



 *From:* zeromq-dev-boun...@lists.zeromq.org [mailto:
 zeromq-dev-boun...@lists.zeromq.org] *On Behalf Of *Thomas Rodgers
 *Sent:* 02 June 2015 16:07
 *To:* ZeroMQ development list
 *Subject:* Re: [zeromq-dev] (almost) zero-copy message receive



 A better chart of compiler conformance is probably here -



 http://en.cppreference.com/w/cpp/compiler_support



 I don't know that there's been a flamewar around this topic, but
 switching to -std=c++11 has been discussed recently in the context of
 implementing thread safe sockets. IIRC the consensus at the time was to
 stick with 98/03 conforming code.



 In my experience, supporting C++11, opens opens up a bit of a minefield of
 portability gotchas. For https://github.com/zeromq/azmq I can generally
 fall back on Boost to paper over these issues, but that's not a realistic
 option with libzmq. So, while I get that *this* change wouldn't necessarily
 run afoul of the current state of C++ conformance for MSVC, I am personally
 a bit leary of the general prospects of switching to C++11 in libzmq
 because the next change that assumes C++11 conformance might not be
 supported by the range of compilers used to build libzmq.







 On Tue, Jun 2, 2015 at 8:44 AM, Auer, Jens jens.a...@cgi.com wrote:

 Hi,

 I don't want to start a flame war on this because I know that there can be
 very good reasons to not rely on C++11. That's why I did not just send the
 patch, but wanted to discuss it first and see if there are any other ways
 to do this.
 The main issue is that I want to put an atomic_counter_t into a union in
 msg_t, which C++98/C++03 does not allow because it has constructors and
 non-public data members. So an obvious way to solve this would be to make
 atomic_counter_t a plain C struct with free function to create and modify
 it. I was hoping for other suggestions.

 For what it's worth, the change does not need a fully compliant C++, but
 just standard layout and trivial types which are implemented in MSVC since
 2012.

 Cheers,
   Jens



 --

 *Jens Auer *| CGI | Software-Engineer

 CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany

 T: +49 6151 36860 154
 jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 de.cgi.com/pflichtangaben.



 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

One other point, you would need to guarantee appropriate alignment of the
backing array (sadly, C++11 gave us std::aligned_storage but 03 not so
much).

On Tue, Jun 2, 2015 at 10:11 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:

 I am unaware of any list, it seems (to me at least) it's whatever people
 have contributed support for.

 As for a concrete suggestion. I am not sure this is any less ugly but...

 libzmq goes out of it's way generally to avoid calling new() in many cases
 (non-throwing failure on OOM presumably), preferring malloc() and placement
 new instead, content_t was no exception. It did embed an explicit
 atomic_counter_t and would placement new it, and explicitly call the
 destructor when the lmsg was destroyed.

 You could, instead declare the storage for atomic_counter_t as an array,
 uint8_t ctr_storage[sizeof(atomic_counter_t)] and placement new/explicit
 dtor as before, and then provide an accessor to return an atomic_counter_t
 by returning *reinterpret_castatomic_counter_t*(ctr_storage[0]).

 It doesn't change the size of the lmsg type, but it does remove one level
 of indirection, and you have hidden the ugly bits behind an accessor method.

 On Tue, Jun 2, 2015 at 9:40 AM, Auer, Jens jens.a...@cgi.com wrote:

  Hi Thomas,



 I did not want to say that you intended to start a flame war and you
 certainly did not. I know that things like these easily turn into flame
 wars, so I wanted to prevent that. All I wanted say was that I know that
 switching to C++11 may not be applicable so I want to discuss the patch
 first and search for an alternative to C++11. Do you have a suggestion for
 the issue with the non-POD atomic_counter_t? My experience is quite
 limited because I normally don’t write code which has to support older
 compilers.



 Just out of curiosity, do you know a definite list of compilers zeroMQ
 intends to supports? I only found the document
 http://zeromq.org/docs:builds, but this is quite outdated.



 Best wishes,

   Jens



 *--*

 *Dr. Jens Auer *| CGI | Software Engineer

 CGI Deutschland Ltd.  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany

 T: +49 6151 36860 154

 jens.a...@cgi.com

 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie
 unter de.cgi.com/pflichtangaben.



 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.



 *From:* zeromq-dev-boun...@lists.zeromq.org [mailto:
 zeromq-dev-boun...@lists.zeromq.org] *On Behalf Of *Thomas Rodgers
 *Sent:* 02 June 2015 16:07
 *To:* ZeroMQ development list
 *Subject:* Re: [zeromq-dev] (almost) zero-copy message receive



 A better chart of compiler conformance is probably here -



 http://en.cppreference.com/w/cpp/compiler_support



 I don't know that there's been a flamewar around this topic, but
 switching to -std=c++11 has been discussed recently in the context of
 implementing thread safe sockets. IIRC the consensus at the time was to
 stick with 98/03 conforming code.



 In my experience, supporting C++11, opens opens up a bit of a minefield
 of portability gotchas. For https://github.com/zeromq/azmq I can
 generally fall back on Boost to paper over these issues, but that's not a
 realistic option with libzmq. So, while I get that *this* change wouldn't
 necessarily run afoul of the current state of C++ conformance for MSVC, I
 am personally a bit leary of the general prospects of switching to C++11 in
 libzmq because the next change that assumes C++11 conformance might not be
 supported by the range of compilers used to build libzmq.







 On Tue, Jun 2, 2015 at 8:44 AM, Auer, Jens jens.a...@cgi.com wrote:

 Hi,

 I don't want to start a flame war on this because I know that there can
 be very good reasons to not rely on C++11. That's why I did not just send
 the patch, but wanted to discuss it first and see if there are any other
 ways to do this.
 The main issue is that I want to put an atomic_counter_t into a union in
 msg_t, which C++98/C++03 does not allow because it has constructors and
 non-public data members. So an obvious way to solve this would be to make
 atomic_counter_t a plain C struct with free function to create and modify
 it. I was hoping for other suggestions.

 For what it's worth, the change does not need a fully compliant C++, but
 just standard layout and trivial types which are implemented in MSVC since
 2012.

 Cheers,
   Jens



 --

 *Jens Auer *| CGI | Software-Engineer

 CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany

 T: +49 6151 36860 154
 jens.a

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

with reinterpret_cast?

On Tue, Jun 2, 2015 at 10:55 AM, Auer, Jens jens.a...@cgi.com wrote:

  I already tried this, but then the compiler complaint about a violation
 of the strict alias rules and the code doesn't compile anymore. The problem
 is that I access something of type uint8_t[] with a pointer of type
 atomic_counter_t.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.
   --
 *Von:* zeromq-dev-boun...@lists.zeromq.org [
 zeromq-dev-boun...@lists.zeromq.org] im Auftrag von Thomas Rodgers [
 rodg...@twrodgers.com]
 *Gesendet:* Dienstag, 2. Juni 2015 17:34

 *An:* ZeroMQ development list
 *Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive

   One other point, you would need to guarantee appropriate alignment of
 the backing array (sadly, C++11 gave us std::aligned_storage but 03 not so
 much).

 On Tue, Jun 2, 2015 at 10:11 AM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 I am unaware of any list, it seems (to me at least) it's whatever people
 have contributed support for.

  As for a concrete suggestion. I am not sure this is any less ugly but...

  libzmq goes out of it's way generally to avoid calling new() in many
 cases (non-throwing failure on OOM presumably), preferring malloc() and
 placement new instead, content_t was no exception. It did embed an explicit
 atomic_counter_t and would placement new it, and explicitly call the
 destructor when the lmsg was destroyed.

  You could, instead declare the storage for atomic_counter_t as an
 array, uint8_t ctr_storage[sizeof(atomic_counter_t)] and placement
 new/explicit dtor as before, and then provide an accessor to return an
 atomic_counter_t by returning
 *reinterpret_castatomic_counter_t*(ctr_storage[0]).

  It doesn't change the size of the lmsg type, but it does remove one
 level of indirection, and you have hidden the ugly bits behind an accessor
 method.

 On Tue, Jun 2, 2015 at 9:40 AM, Auer, Jens jens.a...@cgi.com wrote:

  Hi Thomas,



 I did not want to say that you intended to start a flame war and you
 certainly did not. I know that things like these easily turn into flame
 wars, so I wanted to prevent that. All I wanted say was that I know that
 switching to C++11 may not be applicable so I want to discuss the patch
 first and search for an alternative to C++11. Do you have a suggestion for
 the issue with the non-POD atomic_counter_t? My experience is quite
 limited because I normally don’t write code which has to support older
 compilers.



 Just out of curiosity, do you know a definite list of compilers zeroMQ
 intends to supports? I only found the document
 http://zeromq.org/docs:builds, but this is quite outdated.



 Best wishes,

   Jens



 *--*

 *Dr. Jens Auer *| CGI | Software Engineer

 CGI Deutschland Ltd.  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany

 T: +49 6151 36860 154

 jens.a...@cgi.com

 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie
 unter de.cgi.com/pflichtangaben.



 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging
 to CGI Group Inc. and its affiliates may be contained in this message. If
 you are not a recipient indicated or intended in this message (or
 responsible for delivery of this message to such person), or you think for
 any reason that this message may have been addressed to you in error, you
 may not use or copy or deliver this message to anyone else. In such case,
 you should destroy this message and are asked to notify the sender by reply
 e-mail.



 *From:* zeromq-dev-boun...@lists.zeromq.org [mailto:
 zeromq-dev-boun...@lists.zeromq.org] *On Behalf Of *Thomas Rodgers
 *Sent:* 02 June 2015 16:07
 *To:* ZeroMQ development list
 *Subject:* Re: [zeromq-dev] (almost) zero-copy message receive



 A better chart of compiler conformance is probably here -



 http://en.cppreference.com/w/cpp/compiler_support



 I don't know that there's been a flamewar around this topic, but
 switching to -std=c++11 has been discussed recently in the context of
 implementing thread safe sockets. IIRC the consensus at the time was to
 stick with 98/03 conforming code.



 In my experience, supporting C++11

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

If it were completely broken, then how could vector work (it is the current
poster child for type erased aligned storage)? std::aligned_storage (and
boost::aligned_storage) also do type erasure through a char backing array.
It might well be strictly illegal relative to standards wording (there
was some discussion along these lines at the fall Standards meeting), but
it would essentially preclude any sort of placement new except the via the
magic weasel words that allow malloc.

On Tue, Jun 2, 2015 at 11:30 AM, Auer, Jens jens.a...@cgi.com wrote:

  Yes, this doesn't change anything because it only depends on the
 existence of two pointers of different type pointing to the same address.
 There is an exception for char*, but here we would have a char array and an
 atomic_counter_t pointer pointing to it. This is illegal.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.
   --
 *Von:* zeromq-dev-boun...@lists.zeromq.org [
 zeromq-dev-boun...@lists.zeromq.org] im Auftrag von Thomas Rodgers [
 rodg...@twrodgers.com]
 *Gesendet:* Dienstag, 2. Juni 2015 18:10

 *An:* ZeroMQ development list
 *Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive

   with reinterpret_cast?

 On Tue, Jun 2, 2015 at 10:55 AM, Auer, Jens jens.a...@cgi.com wrote:

  I already tried this, but then the compiler complaint about a violation
 of the strict alias rules and the code doesn't compile anymore. The problem
 is that I access something of type uint8_t[] with a pointer of type
 atomic_counter_t.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.
--
 *Von:* zeromq-dev-boun...@lists.zeromq.org [
 zeromq-dev-boun...@lists.zeromq.org] im Auftrag von Thomas Rodgers [
 rodg...@twrodgers.com]
 *Gesendet:* Dienstag, 2. Juni 2015 17:34

 *An:* ZeroMQ development list
 *Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive

One other point, you would need to guarantee appropriate alignment of
 the backing array (sadly, C++11 gave us std::aligned_storage but 03 not so
 much).

 On Tue, Jun 2, 2015 at 10:11 AM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 I am unaware of any list, it seems (to me at least) it's whatever people
 have contributed support for.

  As for a concrete suggestion. I am not sure this is any less ugly
 but...

  libzmq goes out of it's way generally to avoid calling new() in many
 cases (non-throwing failure on OOM presumably), preferring malloc() and
 placement new instead, content_t was no exception. It did embed an explicit
 atomic_counter_t and would placement new it, and explicitly call the
 destructor when the lmsg was destroyed.

  You could, instead declare the storage for atomic_counter_t as an
 array, uint8_t ctr_storage[sizeof(atomic_counter_t)] and placement
 new/explicit dtor as before, and then provide an accessor to return an
 atomic_counter_t by returning
 *reinterpret_castatomic_counter_t*(ctr_storage[0]).

  It doesn't change the size of the lmsg type, but it does remove one
 level of indirection, and you have hidden the ugly bits behind an accessor
 method.

 On Tue, Jun 2, 2015 at 9:40 AM, Auer, Jens jens.a...@cgi.com wrote:

  Hi Thomas,



 I did not want to say that you intended to start a flame war and you
 certainly did not. I know that things like these easily turn into flame
 wars, so I wanted

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

It is really hard to grok 3.9.2 of the standard regarding type punning
rules, but I *think* you are safe if you make the backing array of either
char or unsigned char. And if 5.2.10 is be believed, reinterpret_cast
*should* work, but it does seem to run afoul of the strict_aliasing
warning, syou have to do a double static_cast through void, e.g. -

void* pv = static_castdvoid*(u.lmsg.content-ref_stg[0]);
return *static_castzmq::atomic_counter_t*(pv);

Boost (serialization, iterator to pointer conversion, flat set/map, etc)
also uses this technique.



On Tue, Jun 2, 2015 at 11:10 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:

 with reinterpret_cast?

 On Tue, Jun 2, 2015 at 10:55 AM, Auer, Jens jens.a...@cgi.com wrote:

  I already tried this, but then the compiler complaint about a violation
 of the strict alias rules and the code doesn't compile anymore. The problem
 is that I access something of type uint8_t[] with a pointer of type
 atomic_counter_t.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.
   --
 *Von:* zeromq-dev-boun...@lists.zeromq.org [
 zeromq-dev-boun...@lists.zeromq.org] im Auftrag von Thomas Rodgers [
 rodg...@twrodgers.com]
 *Gesendet:* Dienstag, 2. Juni 2015 17:34

 *An:* ZeroMQ development list
 *Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive

   One other point, you would need to guarantee appropriate alignment of
 the backing array (sadly, C++11 gave us std::aligned_storage but 03 not so
 much).

 On Tue, Jun 2, 2015 at 10:11 AM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 I am unaware of any list, it seems (to me at least) it's whatever people
 have contributed support for.

  As for a concrete suggestion. I am not sure this is any less ugly
 but...

  libzmq goes out of it's way generally to avoid calling new() in many
 cases (non-throwing failure on OOM presumably), preferring malloc() and
 placement new instead, content_t was no exception. It did embed an explicit
 atomic_counter_t and would placement new it, and explicitly call the
 destructor when the lmsg was destroyed.

  You could, instead declare the storage for atomic_counter_t as an
 array, uint8_t ctr_storage[sizeof(atomic_counter_t)] and placement
 new/explicit dtor as before, and then provide an accessor to return an
 atomic_counter_t by returning
 *reinterpret_castatomic_counter_t*(ctr_storage[0]).

  It doesn't change the size of the lmsg type, but it does remove one
 level of indirection, and you have hidden the ugly bits behind an accessor
 method.

 On Tue, Jun 2, 2015 at 9:40 AM, Auer, Jens jens.a...@cgi.com wrote:

  Hi Thomas,



 I did not want to say that you intended to start a flame war and you
 certainly did not. I know that things like these easily turn into flame
 wars, so I wanted to prevent that. All I wanted say was that I know that
 switching to C++11 may not be applicable so I want to discuss the patch
 first and search for an alternative to C++11. Do you have a suggestion for
 the issue with the non-POD atomic_counter_t? My experience is quite
 limited because I normally don’t write code which has to support older
 compilers.



 Just out of curiosity, do you know a definite list of compilers zeroMQ
 intends to supports? I only found the document
 http://zeromq.org/docs:builds, but this is quite outdated.



 Best wishes,

   Jens



 *--*

 *Dr. Jens Auer *| CGI | Software Engineer

 CGI Deutschland Ltd.  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany

 T: +49 6151 36860 154

 jens.a...@cgi.com

 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie
 unter de.cgi.com/pflichtangaben.



 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging
 to CGI Group Inc. and its affiliates may be contained in this message. If
 you are not a recipient indicated or intended in this message (or
 responsible for delivery of this message to such person), or you think for
 any reason that this message may have been addressed to you in error, you
 may not use or copy or deliver this message to anyone else. In such case,
 you should destroy this message and are asked to notify the sender by reply
 e-mail.



 *From

Re: [zeromq-dev] (almost) zero-copy message receive

[Thomas Rodgers]

Current vector implementations (AFAIK) don't do small object optimizations,
but I have it on good authority (the author sits next to me at work) there
is a proposal coming for such a vector, and it would face the exact same
problem. std::vector does use a dynamically allocated array, but not of
type T, otherwise reserve() would unimplementable. Is the point that a
void* that comes via malloc is somehow different than a member array in
terms of type punning? This may well be strictly true (see aforementioned
malloc standards weasel wording comment), but there are many many
libraries which do small object optimizations via the double static_cast
approach that would break if it didn't work (never mind whether it is
legal). The standard already includes types that do this sort of punning
(std::function, std::aligned_storage, proposed std::optional, proposed
std::variant).

In any event, I've dropped an email to a couple of fellow C++ standards
committee members (including a Clang developer) to see what their thoughts
on this are.



On Tue, Jun 2, 2015 at 11:53 AM, Jens Auer jens.a...@betaversion.net
wrote:

 I always thought that vector uses a dynamically allocated array and not a
 char []. That would give us a char* which we can savely cast into another
 pointer. I don't have the source available, but if it uses small object
 optimization, it has to use a static array backend. I will take a look at
 the vector source code.

 Thanks,
  Jens



  Ursprüngliche Nachricht 
 Von: Thomas Rodgers rodg...@twrodgers.com
 Datum: 02.06.2015 18:37 (GMT+01:00)
 An: ZeroMQ development list zeromq-dev@lists.zeromq.org
 Betreff: Re: [zeromq-dev] (almost) zero-copy message receive


 If it were completely broken, then how could vector work (it is the
 current poster child for type erased aligned storage)? std::aligned_storage
 (and boost::aligned_storage) also do type erasure through a char backing
 array. It might well be strictly illegal relative to standards wording
 (there was some discussion along these lines at the fall Standards
 meeting), but it would essentially preclude any sort of placement new
 except the via the magic weasel words that allow malloc.

 On Tue, Jun 2, 2015 at 11:30 AM, Auer, Jens jens.a...@cgi.com wrote:

  Yes, this doesn't change anything because it only depends on the
 existence of two pointers of different type pointing to the same address.
 There is an exception for char*, but here we would have a char array and an
 atomic_counter_t pointer pointing to it. This is illegal.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.
   --
 *Von:* zeromq-dev-boun...@lists.zeromq.org [
 zeromq-dev-boun...@lists.zeromq.org] im Auftrag von Thomas Rodgers [
 rodg...@twrodgers.com]
 *Gesendet:* Dienstag, 2. Juni 2015 18:10

 *An:* ZeroMQ development list
 *Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive

   with reinterpret_cast?

 On Tue, Jun 2, 2015 at 10:55 AM, Auer, Jens jens.a...@cgi.com wrote:

  I already tried this, but then the compiler complaint about a
 violation of the strict alias rules and the code doesn't compile anymore.
 The problem is that I access something of type uint8_t[] with a pointer of
 type atomic_counter_t.

 Cheers,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging
 to CGI Group Inc. and its affiliates may be contained in this message. If
 you are not a recipient indicated or intended in this message (or
 responsible for delivery of this message to such person), or you think for
 any reason that this message may have been addressed to you in error, you
 may not use or copy or deliver this message to anyone else. In such case,
 you should destroy this message and are asked to notify the sender by reply
 e-mail.
--
 *Von:* zeromq-dev

Re: [zeromq-dev] Endianness conversion functions

[Thomas Rodgers]

  (but it is on the criticl path for large messages)


If you were using this approach to encode fields in some general
serialization format, maybe it would make a measurable difference, but it
seems unlikely to do so relative to framing ZeroMQ messages. In the worst
case the put|get_uint64 (inlined) call is made once per message part in a
multi-part message to convert 8 bytes (for small frames it stores a single
octet).

See also - http://rfc.zeromq.org/spec:37


On Mon, May 11, 2015 at 3:56 PM, Auer, Jens jens.a...@cgi.com wrote:

  Hi,

 I've looking at the zeroMQ source code a little bit and was surprised that
 wire.hpp implements custom endianess converison function to convert 16, 32
 and 64 bit values from/to network byte-order. Is there any reason for not
 using available functions like hton* or htobe family on Linux? I am sure it
 is a micro-optimization (but it is on the criticl path for large messages),
 but recent Intel CPUs provide an assembler instruction which could be used
 with the __builtin_bswap64 intrinsic for gcc and icc.

 Best wishes,
   Jens

  --
  *Jens Auer *| CGI | Software-Engineer
  CGI (Germany) GmbH  Co. KG
 Rheinstraße 95 | 64295 Darmstadt | Germany
 T: +49 6151 36860 154
 *jens.a...@cgi.com* jens.a...@cgi.com
 Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
 *de.cgi.com/pflichtangaben* http://de.cgi.com/pflichtangaben.

 CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
 CGI Group Inc. and its affiliates may be contained in this message. If you
 are not a recipient indicated or intended in this message (or responsible
 for delivery of this message to such person), or you think for any reason
 that this message may have been addressed to you in error, you may not use
 or copy or deliver this message to anyone else. In such case, you should
 destroy this message and are asked to notify the sender by reply e-mail.

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] How many messages are in queue now?

[Thomas Rodgers]

At the point a message is placed on the queue it is either at HWM or has at
least space for one message, this can be evaluated atomically, claiming the
'slot' under the HWM for the message to be placed on the queue. Any other
threads attempting to send would synchronize with this operation and the
HWM will be respected, no overshoot.

Any observation of an atomic count, as it is being changed, will be the
state of the count, at some point in the past. So you could have a HWM of
1000, read a count of 850, make some decision, yah, cool to send, 90%, and
have a failing subsequent send, because in the time it took you to do all
of that, another thread may have enqueued 30 messages, and yet another
thread may have tried to enqueue 50 messages.

Any such observations of queue depth with multiple producers and consumers are
at best, estimates of queue state at some point in the past, and it is very
difficult IME to build reliable logic around that information.

On Friday, April 17, 2015, Ilja Golshtein ilej...@narod.ru wrote:

 Hello Pieter,

 thank you for your answer.

 I am in process of reading http://zguide.zeromq.org/hx:chapter7 , while
 atomic counter seems more natural choice for inproc so far.

 Could you please explain why it is possible to detect that we are at 100%
 of HWM and it is not possible to detect that we are e.g. at 90% ?

 17.04.2015, 11:54, Pieter Hintjens p...@imatix.com javascript:;:
  It was never possible, due to the fact that pipes are being written
  and read asynchronously. You cannot measure the free space except by
  stopping everything.
 
  The workaround is to use credit based flow control. I've a section in
  the Guide that explains how this works. You can in effect know what %
  of the pipe from sender to receiver (including all ZeroMQ and network
  buffers) is filled.
 
  -Pieter
 
  On Wed, Apr 15, 2015 at 4:30 PM, Ilja Golshtein ilej...@narod.ru
 javascript:; wrote:
   Hello.
 
   I used to think that it is possible to retrieve number or queued
 messages per socket in recent versions of 0mq, while I failed to find
 correspond getsockopt in 4.0.5
 
   Use case: I need to alter behavior of my application (drop certain
 type of messages) if a queue is, say, 90% of HWM.
 
   Please, advise if this facility is implemented or planned, or suggest
 a workaround which is more elegant than having atomic variable (it is
 inproc) maintained by reader and writer threads which is what I plan to do.
 
   Thanks.
 
   --
   Best regards
   Ilja Golshtein
   ___
   zeromq-dev mailing list
   zeromq-dev@lists.zeromq.org javascript:;
   http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org javascript:;
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev

 --
 Best regards
 Ilja Golshtein
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org javascript:;
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] How many messages are in queue now?

[Thomas Rodgers]

Patches welcome.

On Friday, April 17, 2015, Ilja Golshtein ilej...@narod.ru wrote:

 Yes, this is true.

 If a sysadmin detects that a disk storage is 90% full, she notifies users
 and do other things to obtain more room, while it is quite possible that
 the disk is only 89% full at the moment.
 So, ability to calculate disk usage is a likely source of confusion and
 gnashing of teeth.
 Right.


 17.04.2015, 17:06, Thomas Rodgers rodg...@twrodgers.com
 javascript:_e(%7B%7D,'cvml','rodg...@twrodgers.com');:

 I suppose then it is a question of general utility. Even with ZMQ_PAIR, it
 is still at best and estimate, likely to have changed (perhaps
 considerably) from the time you query it to the the time you did something
 based on that information. Even under the best of circumstances it seems of
 such limited utility (and a likely source of confusion and gnashing of
 teeth) that I don't see the value in adding the feature.

 On Fri, Apr 17, 2015 at 9:00 AM, Ilja Golshtein ilej...@narod.ru
 javascript:_e(%7B%7D,'cvml','ilej...@narod.ru'); wrote:

 Thomas,

 Agree that it makes perfect sense for multiple producers and consumers,
 while in my case it is ZMQ_PAIR.

 Thanks.

 17.04.2015, 16:49, Thomas Rodgers rodg...@twrodgers.com
 javascript:_e(%7B%7D,'cvml','rodg...@twrodgers.com');:

 At the point a message is placed on the queue it is either at HWM or has
 at least space for one message, this can be evaluated atomically, claiming
 the 'slot' under the HWM for the message to be placed on the queue. Any
 other threads attempting to send would synchronize with this operation and
 the HWM will be respected, no overshoot.

 Any observation of an atomic count, as it is being changed, will be the
 state of the count, at some point in the past. So you could have a HWM of
 1000, read a count of 850, make some decision, yah, cool to send, 90%, and
 have a failing subsequent send, because in the time it took you to do all
 of that, another thread may have enqueued 30 messages, and yet another
 thread may have tried to enqueue 50 messages.

 Any such observations of queue depth with multiple producers and consumers are
 at best, estimates of queue state at some point in the past, and it is very
 difficult IME to build reliable logic around that information.

 On Friday, April 17, 2015, Ilja Golshtein ilej...@narod.ru
 javascript:_e(%7B%7D,'cvml','ilej...@narod.ru'); wrote:

 Hello Pieter,

 thank you for your answer.

 I am in process of reading http://zguide.zeromq.org/hx:chapter7 , while
 atomic counter seems more natural choice for inproc so far.

 Could you please explain why it is possible to detect that we are at 100%
 of HWM and it is not possible to detect that we are e.g. at 90% ?

 17.04.2015, 11:54, Pieter Hintjens p...@imatix.com:
  It was never possible, due to the fact that pipes are being written
  and read asynchronously. You cannot measure the free space except by
  stopping everything.
 
  The workaround is to use credit based flow control. I've a section in
  the Guide that explains how this works. You can in effect know what %
  of the pipe from sender to receiver (including all ZeroMQ and network
  buffers) is filled.
 
  -Pieter
 
  On Wed, Apr 15, 2015 at 4:30 PM, Ilja Golshtein ilej...@narod.ru
 wrote:
   Hello.
 
   I used to think that it is possible to retrieve number or queued
 messages per socket in recent versions of 0mq, while I failed to find
 correspond getsockopt in 4.0.5
 
   Use case: I need to alter behavior of my application (drop certain
 type of messages) if a queue is, say, 90% of HWM.
 
   Please, advise if this facility is implemented or planned, or suggest
 a workaround which is more elegant than having atomic variable (it is
 inproc) maintained by reader and writer threads which is what I plan to do.
 
   Thanks.
 
   --
   Best regards
   Ilja Golshtein
   ___
   zeromq-dev mailing list
   zeromq-dev@lists.zeromq.org
   http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev

 --
 Best regards
 Ilja Golshtein
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

 ,

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org');
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev



 --
 Best regards
 Ilja Golshtein


 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org');
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

 ,

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 javascript:_e(%7B%7D,'cvml','zeromq

Re: [zeromq-dev] Pass arguments via zthread_fork

[Thomas Rodgers]

The pointer you passed is the args[], which is stack local. By the time the
spawned thread starts, that stack frame has been unwound and the two
contained char* are pointing to who knows what.

You must guarantee the lifetime of anything passed by pointer is sufficient
that the receiving thread can read valid memory which is not what you have
in this case. Guaranteeing this can get tricky, which is why the usual
guidance is to share data via message passing.

On Tuesday, April 14, 2015, Bachmair Florian - flexSolution GmbH 
florian.bachm...@flexsolution.eu wrote:

  Hi!

 I have a *char[] with parameter which I wanna hand over to my subscriber
 thread.
 I tried it with my own method which needs an void-pointer as well. There I
 can read the parameters sucesffuly, but not If I start a Thread via
 zthread_fork

 Here's some sample code to Illustrate my problem

 static void fillArguments(){
 char* args[2];
 args[1]=a;
 args[2]=b;
 anyMethod(args);
 zthread_fork(context, subscriber_thread, args);
 }
 //Here it works fine
 static void anyMethod(void *args) {
 puts(anyMethod begin);
 char **strargs = (char **) args;
 puts(strargs[0]);
 puts(strargs[1]);
 fflush(stdout);
 puts(anyMethod end);
 }
 //Here I can't read the parameters, Just get weired values
 static void subscriber_thread(void *args, zctx_t *ctx, void *pipe) {
 puts(Subscribe thread);
 fflush(stdout);

 char **strargs = (char **) args;

 int i;
 puts(strargs[0]);
 puts(strargs[1]);
 fflush(stdout);
 }

 Thx
 Florian

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Canonical language for the Guide

[Thomas Rodgers]

+1

libzmq has always been a C library.  The canonical samples should also be
C. If the goal is clarity of intent, examples based on other language
bindings should be able to do at least as well as CZMQ as the benchmark.

On Tuesday, April 7, 2015, Brian Knox bk...@digitalocean.com wrote:

 I think that C/CZMQ is a reasonable choice.

 I'm intrigued by the idea of being able to generate examples in different
 languages from a DSL - but concerned it might add confusion instead of
 clarity.

 Brian



 On Tue, Apr 7, 2015 at 2:35 PM, Gregg Irwin gr...@pointillistic.com
 javascript:_e(%7B%7D,'cvml','gr...@pointillistic.com'); wrote:

 Hi Pieter,

 PH What's the best canonical language?

 PH My personal preference is C/CZMQ, which is high level and clean.

 PH My second choice would be a high level modeling language.

 +1

 While my only daily C is the vitamin, I think C is the best choice. As
 you say, you will never please everyone. Of course, I'm also a huge
 fan of DSLs and code generators. The issue I see in this context is
 that the bindings, and 0MQ itself, are moving targets. The upside is
 that the old generators are still valid even as you create new
 templates when change comes.

 If you can keep the DSL/MOP simple enough, it could be a win even if
 only used for the C examples. The more general it needs to be, the
 more gratification may be delayed. Do you have thoughts or examples on
 the language or output side already gestating?

 -- Gregg

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org');
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Assertion failure in mailbox.cpp

[Thomas Rodgers]

can you get a stacktrace?

On Thu, Apr 2, 2015 at 9:27 AM, Dario Meloni mello...@gmail.com wrote:



 On Tue, 27 May 2014 10:55:57 +0100, Jon Gjengset wrote:

 I have this problem constantly in a software I am developing in my
 company with ZMQ 4.0.4.
 The issue arise in the same situation, one thread reading and one writing
 in socket pairs inproc. When stress testing the application the assertion
 will trigger sooner or later, but on reading from the sockets, not
 shutting down.

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Which c++ binding choose

[Thomas Rodgers]

I am the author of azmq it is an active project (most recent commit within
the last week).

It is heavily tied to the way that Boost Asio does things. If you already
have/plan on having a dependency on the Boost libraries and are comfortable
with Asio then perhaps it will be a fit for you.

On Friday, March 13, 2015, Leonard Michelet leonard.miche...@openwide.fr
wrote:

 Hello everyone, I must use zeromq for a work project written in c++ and I
 wonder which c++ binding I should use.
 On the c++ binding page (http://zeromq.org/bindings:cpp), there are 3 of
 them, but I'm not sure if each of them are still active.
 Thank you,
 Léonard.
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org javascript:;
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Re : Re: Which c++ binding choose

[Thomas Rodgers]

 I looked to azmq CMakelists and I seems mandatory to have/use boost no?


Boost is mandatory, yes. It would be possible (and not particularly
difficult) to make a version that works with the standalone
http://think-async.com/Asio Asio library, but as all of my projects
assume the use of Boost, it hasn't been a priority for me.

On Friday, March 13, 2015, Leonard Michelet leonard.miche...@openwide.fr
wrote:

 I'm using c++11, but not boost :(
 I started using cppzmq but I miss some functions :
 Stopping socket monitor properly.
 Detected client deconnection from server side (without using a PUB socket).

 I looked to azmq CMakelists and I seems mandatory to have/use boost no?
 Thanks for answering.

 - Thomas Rodgers rodg...@twrodgers.com a écrit :
  I am the author of azmq it is an active project (most recent commit
 within
  the last week).
 
  It is heavily tied to the way that Boost Asio does things. If you already
  have/plan on having a dependency on the Boost libraries and are
 comfortable
  with Asio then perhaps it will be a fit for you.
 
  On Friday, March 13, 2015, Leonard Michelet 
 leonard.miche...@openwide.fr
  wrote:
 
   Hello everyone, I must use zeromq for a work project written in c++
 and I
   wonder which c++ binding I should use.
   On the c++ binding page (http://zeromq.org/bindings:cpp), there are 3
 of
   them, but I'm not sure if each of them are still active.
   Thank you,
   Léonard.
   ___
   zeromq-dev mailing list
   zeromq-dev@lists.zeromq.org javascript:;
   http://lists.zeromq.org/mailman/listinfo/zeromq-dev
  

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] thread safe sockets and ZMQ_FD

[Thomas Rodgers]

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
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] thread safe sockets and ZMQ_FD

[Thomas Rodgers]

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 these socket types be used in a polling reactor
 then?

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] thread safe sockets and ZMQ_FD

[Thomas Rodgers]

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 to
just make that API get_sockopt() for ZMQ_FD but make the FD returned the
'new' signaling one?

On Saturday, February 21, 2015, Doron Somech somdo...@gmail.com wrote:

 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 added to each of the associated thread safe sockets.

 The mailbox_safe type already (
 https://github.com/zeromq/libzmq/blob/master/src/mailbox_safe.hpp) have a
 method called add signaler which is actually a file descriptor.




 On Sat, Feb 21, 2015 at 5:27 PM, Thomas Rodgers rodg...@twrodgers.com
 javascript:_e(%7B%7D,'cvml','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 these socket types be used in a polling reactor
 then?

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org');
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] thread safe sockets and ZMQ_FD

[Thomas Rodgers]

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 at this point.

 Many of the issues below would just 'go away' with the use of std::mutex,
 std::unique_lock, and std::comdition_variable.


 On Saturday, February 21, 2015, 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 workaround in the destructor is not thread-safe. Another thread
 may enter and wait between the sync-unlock() and the end of the
 destructor scope. You need to add a state variable to prevent this
 from happening.

 Furthermore, if another thread is waiting on the condition variable,
 then the mutex is unlocked while it is waiting. You need to
 notify (broadcast) the condition variable to wake up the other thread
 and get it out of the class. You will most likely need to to add a
 reference count to keep track of how many pending threads are waiting
 in order to know when it is safe to exit the destructor.

 The use of sync-lock() and sync-unlock() is not exception safe. I
 suggest that you use a scoped lock instead of the explicit calls. Read
 this for inspiration:

http://en.cppreference.com/w/cpp/thread/unique_lock

 The code does not handle spurious wakeups from the condition variable.

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] thread safe sockets and ZMQ_FD

[Thomas Rodgers]

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,
std::unique_lock, and std::comdition_variable.

On Saturday, February 21, 2015, 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 workaround in the destructor is not thread-safe. Another thread
 may enter and wait between the sync-unlock() and the end of the
 destructor scope. You need to add a state variable to prevent this
 from happening.

 Furthermore, if another thread is waiting on the condition variable,
 then the mutex is unlocked while it is waiting. You need to
 notify (broadcast) the condition variable to wake up the other thread
 and get it out of the class. You will most likely need to to add a
 reference count to keep track of how many pending threads are waiting
 in order to know when it is safe to exit the destructor.

 The use of sync-lock() and sync-unlock() is not exception safe. I
 suggest that you use a scoped lock instead of the explicit calls. Read
 this for inspiration:

http://en.cppreference.com/w/cpp/thread/unique_lock

 The code does not handle spurious wakeups from the condition variable.

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org javascript:;
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] thread safe sockets and ZMQ_FD

[Thomas Rodgers]

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 be both exception safe and have a chance of not biting someone
down the road.

Also, std::condition_variable has explicit support for handling spurious
wakeups. see -

http://en.cppreference.com/w/cpp/thread/condition_variable/wait

The second variant of wait() takes a predicate which can be used to ignore
spurious wakeups.


On Sat, Feb 21, 2015 at 10:51 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:

 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 at this point.

 Many of the issues below would just 'go away' with the use of std::mutex,
 std::unique_lock, and std::comdition_variable.


 On Saturday, February 21, 2015, 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 workaround in the destructor is not thread-safe. Another thread
 may enter and wait between the sync-unlock() and the end of the
 destructor scope. You need to add a state variable to prevent this
 from happening.

 Furthermore, if another thread is waiting on the condition variable,
 then the mutex is unlocked while it is waiting. You need to
 notify (broadcast) the condition variable to wake up the other thread
 and get it out of the class. You will most likely need to to add a
 reference count to keep track of how many pending threads are waiting
 in order to know when it is safe to exit the destructor.

 The use of sync-lock() and sync-unlock() is not exception safe. I
 suggest that you use a scoped lock instead of the explicit calls. Read
 this for inspiration:

http://en.cppreference.com/w/cpp/thread/unique_lock

 The code does not handle spurious wakeups from the condition variable.

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] thread safe sockets and ZMQ_FD

[Thomas Rodgers]

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:

 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 1:17 PM, Doron Somech somdo...@gmail.com
 javascript:_e(%7B%7D,'cvml','somdo...@gmail.com'); wrote:

 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
 javascript:_e(%7B%7D,'cvml','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 workaround in the destructor is not thread-safe. Another thread
 may enter and wait between the sync-unlock() and the end of the
 destructor scope. You need to add a state variable to prevent this
 from happening.

 Furthermore, if another thread is waiting on the condition variable,
 then the mutex is unlocked while it is waiting. You need to
 notify (broadcast) the condition variable to wake up the other thread
 and get it out of the class. You will most likely need to to add a
 reference count to keep track of how many pending threads are waiting
 in order to know when it is safe to exit the destructor.

 The use of sync-lock() and sync-unlock() is not exception safe. I
 suggest that you use a scoped lock instead of the explicit calls. Read
 this for inspiration:

http://en.cppreference.com/w/cpp/thread/unique_lock

 The code does not handle spurious wakeups from the condition variable.

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org');
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev


 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 javascript:_e(%7B%7D,'cvml','zeromq-dev@lists.zeromq.org');
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

libzmq has had io_vec like send/receive for a while (zmq_sendiov,
zmq_recviov), there is no documentation for them however.

On Fri, Feb 6, 2015 at 2:40 PM, Michel Pelletier pelletier.mic...@gmail.com
 wrote:

 Something else that occurred to me today, perhaps incorrectly, is that
 there was mention that nanomsg doesn't have multipart messages, but it does
 still preserve multipart messages in a way, but supporting scatter and
 gather io vectors.  Perhaps emulating this well known API pattern is the
 right approach to moving forward that still keep everyone happy and brings
 us closer to the ability to have thread safety.

 -Michel

 On Fri, Feb 6, 2015 at 12:28 PM, MinRK benjami...@gmail.com wrote:

 If I recall correctly, libzmq-3.0 (or was it the old 4.0 experimental
 branch?) preserved multi-hop while separating routing from content by
 making the routing id a sequence rather than a single value. That way, it
 seems that the same push/pop behavior that happens on a ROUTER-DEALER
 device today could still work on CLIENT-SERVER. The push/pop would be
 happening on the routing stack instead of message content.

 If a message were something like:

 {
frame_t frames[];
int nframes;
routing_id_t route[];
int nroutes;
 }

 it would seem that you could have multi-part content (selfishly, in the
 way that affects me - messages composed of non-contiguous memory),
 multi-hop routing, and send it all with a single `zmq_send_newfangled`
 call, allowing future attempts at making `zmq_send_newfangled` a threadsafe
 call.

 There may be reasons this would be super gross and horrible, but it's an
 idea, anyway.

 -MinRK


 On Fri, Feb 6, 2015 at 9:02 AM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 Adding a mutex, even one that is never contended, to the socket will
 essentially triple this (one atomic CAS to acquire the mutex, one atomic
 CAS to put the message on the pipe, one atomic CAS to release the mutex).


 This is a bit of a blue sky view of the cost of acquiring a mutex. For
 the adventurous of spirit, chase down the call path of pthread_mutex
 sometime in GLIBC. It is substantially more involved than a single pair of
 'lock; cmpxchg' instructions, but it tries really hard to make that the
 rough cost of the happy path.

 On Fri, Feb 6, 2015 at 9:41 AM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 Having thought about this for a couple of more days, I want to at least
 take a stab at arguing against threadsafe sockets -

 libzmq's thread safety guarantees, to me anyway, are very clear,
 unsurprising and non-controversial - I cannot share a socket with another
 thread without a full fence.

 The kinds of systems I generally build have very strict requirements on
 overall latency, to the point that most of my networking IO is done through
 kernel-bypass libraries and NICs that support this, for raw TCP and UDP
 multicast. The latency sensitive code that does IO is in it's own thread,
 with exclusive access to the NICs which are accessed via kernel bypass.
 Coordination with other threads in the same process is done via inproc pair
 sockets. Pair sockets + very small messages (small enough that libzmq does
 not need to perform allocation) provide a very nice interface to a lock
 free queue with low overhead using a single atomic CAS operation. Atomic
 operations are cheap, but they are not free (~30 clocks on x86). Adding a
 mutex, even one that is never contended, to the socket will essentially
 triple this (one atomic CAS to acquire the mutex, one atomic CAS to put the
 message on the pipe, one atomic CAS to release the mutex). I would like to
 have the option to avoid this.

 If a wrapper wants thread safe sockets to enable certain use-cases that
 may be more idiomatic for the language in question, it can provide the full
 fence. AZMQ https://github.com/zeromq/azmq does exactly this by
 default, but you have the option to opt out of it. It does this because
 Boost Asio by default allows it's sockets to be used from multiple threads
 for async IO and I need to guard more than just exclusive access to the
 ZeroMQ socket a the fence in this case. Putting a mutex inside of the
 libzmq socket, essentially doubles the overhead for no gain in useful
 functionality and runs completely counter to one of C and C++'s overarching
 principles: don't pay for what you don't use.

 If a class of apps really demands short lived exclusive access to a
 socket, provide a pool abstraction. The pool is thread safe, obtain a
 socket, perform I/O in a single thread, return the socket to the pool.

 On Wed, Feb 4, 2015 at 1:04 PM, Michel Pelletier 
 pelletier.mic...@gmail.com wrote:



 On Wed, Feb 4, 2015 at 10:51 AM, Pieter Hintjens p...@imatix.com
 wrote:

 The discussion about thread safety was quite short iirc, though that
 contributor did discuss other things... at length. I merged his
 thread safe socket change rapidly, then we reverted it after a few
 days, and he disappeared. It was rather brute force

Re: [zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

Having thought about this for a couple of more days, I want to at least
take a stab at arguing against threadsafe sockets -

libzmq's thread safety guarantees, to me anyway, are very clear,
unsurprising and non-controversial - I cannot share a socket with another
thread without a full fence.

The kinds of systems I generally build have very strict requirements on
overall latency, to the point that most of my networking IO is done through
kernel-bypass libraries and NICs that support this, for raw TCP and UDP
multicast. The latency sensitive code that does IO is in it's own thread,
with exclusive access to the NICs which are accessed via kernel bypass.
Coordination with other threads in the same process is done via inproc pair
sockets. Pair sockets + very small messages (small enough that libzmq does
not need to perform allocation) provide a very nice interface to a lock
free queue with low overhead using a single atomic CAS operation. Atomic
operations are cheap, but they are not free (~30 clocks on x86). Adding a
mutex, even one that is never contended, to the socket will essentially
triple this (one atomic CAS to acquire the mutex, one atomic CAS to put the
message on the pipe, one atomic CAS to release the mutex). I would like to
have the option to avoid this.

If a wrapper wants thread safe sockets to enable certain use-cases that may
be more idiomatic for the language in question, it can provide the full
fence. AZMQ https://github.com/zeromq/azmq does exactly this by default,
but you have the option to opt out of it. It does this because Boost Asio
by default allows it's sockets to be used from multiple threads for async
IO and I need to guard more than just exclusive access to the ZeroMQ socket
a the fence in this case. Putting a mutex inside of the libzmq socket,
essentially doubles the overhead for no gain in useful functionality and
runs completely counter to one of C and C++'s overarching principles:
don't pay for what you don't use.

If a class of apps really demands short lived exclusive access to a socket,
provide a pool abstraction. The pool is thread safe, obtain a socket,
perform I/O in a single thread, return the socket to the pool.

On Wed, Feb 4, 2015 at 1:04 PM, Michel Pelletier pelletier.mic...@gmail.com
 wrote:



 On Wed, Feb 4, 2015 at 10:51 AM, Pieter Hintjens p...@imatix.com wrote:

 The discussion about thread safety was quite short iirc, though that
 contributor did discuss other things... at length. I merged his
 thread safe socket change rapidly, then we reverted it after a few
 days, and he disappeared. It was rather brute force and I suspect did
 not work at all, it simply wrapped all accesses to the socket
 structure in mutexes. No discussion at the time of multipart data and
 atomic send/recv.


 My memory of the conversation at the time is pretty dim, I agree the
 changes were ugly and untested and the contributor was difficult to reason
 with and seemed to want to make the changes based on no real need at all.



 As for socket safety, I've no strong opinion. I see that many people
 expect that to work and hit errors when it doesn't. I see that nanomsg
 has threadsafe sockets and no multipart. I see that sharing sockets
 across threads would make some actor models simpler, which is nice.


 This is the classic problem with thread safe anything.  Threads are hard,
 and there is a balance between the complexity of making a thread safe
 construct and the skill required of a programmer to use unsafe construct
 in a safe manner.  I still think if the concrete problem is very short
 lived threads causing slow joiner problems, then the simple solution is
 pools (troupes of actors?).

 -Michel








 On Wed, Feb 4, 2015 at 7:35 PM, Michel Pelletier
 pelletier.mic...@gmail.com wrote:
  I think Brian has some good points here, there are numerous unrelated
 issues
  being discussed in this thread.
 
  A few points that I have:
 
  Multi part messages have also bothered me.  However as a Python
 programmer i
  see Min's points about the expense of buffer creation.  To my knowledge
  zproto does not (yet) have Python generation support either, or maybe
  something like generated cffi or ctypes wrappers around the zproto
 generated
  C code.  That being said there are a variety of serialization libraries
 for
  Python.  With some ctypes and mmap magic they can also be done zero
 copy
  but it's not pretty:
 
  https://gist.github.com/michelp/7522179
 
  Multi part envelops are also how multi-hop routing is done.  I don't
 see how
  the new ideas handle that.  I don't think we can just say multi hop
 routing
  is bad and get rid of it.
 
  Thread safe sockets do not sound appealing to me.  We did that, had a
 long
  and contentious discussion with the person championing them, merged it,
 then
  reverted it and that person is now no longer in the community.  Pieter
 was
  the most vocal opponent to them then and now he wants them back.  Of
 course,
  anyone can change their mind, but 

Re: [zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

 Adding a mutex, even one that is never contended, to the socket will
 essentially triple this (one atomic CAS to acquire the mutex, one atomic
 CAS to put the message on the pipe, one atomic CAS to release the mutex).


This is a bit of a blue sky view of the cost of acquiring a mutex. For
the adventurous of spirit, chase down the call path of pthread_mutex
sometime in GLIBC. It is substantially more involved than a single pair of
'lock; cmpxchg' instructions, but it tries really hard to make that the
rough cost of the happy path.

On Fri, Feb 6, 2015 at 9:41 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:

 Having thought about this for a couple of more days, I want to at least
 take a stab at arguing against threadsafe sockets -

 libzmq's thread safety guarantees, to me anyway, are very clear,
 unsurprising and non-controversial - I cannot share a socket with another
 thread without a full fence.

 The kinds of systems I generally build have very strict requirements on
 overall latency, to the point that most of my networking IO is done through
 kernel-bypass libraries and NICs that support this, for raw TCP and UDP
 multicast. The latency sensitive code that does IO is in it's own thread,
 with exclusive access to the NICs which are accessed via kernel bypass.
 Coordination with other threads in the same process is done via inproc pair
 sockets. Pair sockets + very small messages (small enough that libzmq does
 not need to perform allocation) provide a very nice interface to a lock
 free queue with low overhead using a single atomic CAS operation. Atomic
 operations are cheap, but they are not free (~30 clocks on x86). Adding a
 mutex, even one that is never contended, to the socket will essentially
 triple this (one atomic CAS to acquire the mutex, one atomic CAS to put the
 message on the pipe, one atomic CAS to release the mutex). I would like to
 have the option to avoid this.

 If a wrapper wants thread safe sockets to enable certain use-cases that
 may be more idiomatic for the language in question, it can provide the full
 fence. AZMQ https://github.com/zeromq/azmq does exactly this by
 default, but you have the option to opt out of it. It does this because
 Boost Asio by default allows it's sockets to be used from multiple threads
 for async IO and I need to guard more than just exclusive access to the
 ZeroMQ socket a the fence in this case. Putting a mutex inside of the
 libzmq socket, essentially doubles the overhead for no gain in useful
 functionality and runs completely counter to one of C and C++'s overarching
 principles: don't pay for what you don't use.

 If a class of apps really demands short lived exclusive access to a
 socket, provide a pool abstraction. The pool is thread safe, obtain a
 socket, perform I/O in a single thread, return the socket to the pool.

 On Wed, Feb 4, 2015 at 1:04 PM, Michel Pelletier 
 pelletier.mic...@gmail.com wrote:



 On Wed, Feb 4, 2015 at 10:51 AM, Pieter Hintjens p...@imatix.com wrote:

 The discussion about thread safety was quite short iirc, though that
 contributor did discuss other things... at length. I merged his
 thread safe socket change rapidly, then we reverted it after a few
 days, and he disappeared. It was rather brute force and I suspect did
 not work at all, it simply wrapped all accesses to the socket
 structure in mutexes. No discussion at the time of multipart data and
 atomic send/recv.


 My memory of the conversation at the time is pretty dim, I agree the
 changes were ugly and untested and the contributor was difficult to reason
 with and seemed to want to make the changes based on no real need at all.



 As for socket safety, I've no strong opinion. I see that many people
 expect that to work and hit errors when it doesn't. I see that nanomsg
 has threadsafe sockets and no multipart. I see that sharing sockets
 across threads would make some actor models simpler, which is nice.


 This is the classic problem with thread safe anything.  Threads are hard,
 and there is a balance between the complexity of making a thread safe
 construct and the skill required of a programmer to use unsafe construct
 in a safe manner.  I still think if the concrete problem is very short
 lived threads causing slow joiner problems, then the simple solution is
 pools (troupes of actors?).

 -Michel








 On Wed, Feb 4, 2015 at 7:35 PM, Michel Pelletier
 pelletier.mic...@gmail.com wrote:
  I think Brian has some good points here, there are numerous unrelated
 issues
  being discussed in this thread.
 
  A few points that I have:
 
  Multi part messages have also bothered me.  However as a Python
 programmer i
  see Min's points about the expense of buffer creation.  To my knowledge
  zproto does not (yet) have Python generation support either, or maybe
  something like generated cffi or ctypes wrappers around the zproto
 generated
  C code.  That being said there are a variety of serialization
 libraries for
  Python.  With some ctypes

Re: [zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

 * Sessions require protocol commands that are invisible to normal
 use. That means either protocol support (e.g. command frames) or some
 layering on top of ZeroMQ blobs.


What would the argument be for not just using command frames for this?

On Tue, Feb 3, 2015 at 4:04 PM, Pieter Hintjens p...@imatix.com wrote:

 Thanks for the questions. I'd try to flatter by saying how great these
 questions are, except I know you're all way too smart to fall for
 that. :)

 Let me answer a bunch of questions in one go:

 * Sorry for not posting this here. I've written a more detailed
 analysis of the motivation for this thread (and experiments):
 http://hintjens.com/blog:84.

 * The main goal with this is simplicity and accuracy. I'm tired of
 teaching people ZeroMQ constructs that are clearly over-designed and
 disconnected from reality in subtle ways. Each apology for friction
 (sorry, but don't use REQ-REP, they are kind of weird, sorry,
 IDENTITY is not really identity, sorry, message sometimes means
 frame and sometimes message) really signals costs up and down the
 stacks.

 * Sessions require protocol commands that are invisible to normal
 use. That means either protocol support (e.g. command frames) or some
 layering on top of ZeroMQ blobs.

 * Picture sending solves a cross-language problem, namely how to
 construct zproto-style commands without using dedicated codecs. While
 the API is C-ish, the functionality is not. I'd expect that to be
 wrapped in bindings.

 * Per-language serialization is an anti-pattern. It's common, and fine
 as such, yet ZeroMQ should IMO always strive to be cross-language.

 * REQ-REP between threads may make sense. We certainly use it (ZAP,
 for authentication).

 * Is this discussion C4 compatible? Yes, no, this is chatter, not a
 plan or roadmap. Until pull requests hit the road, it's all vapour.
 However the problems I restated in my blog article are real, to many
 people, and should be aired.

 * Multipart does easy serialization, yes. Not in C though. We've
 learned how to do variable list serialization with zproto-compatible
 picture sending in CZMQ. Is this a sufficient alternative? I think so.
 zsock_send() was essential to making actors cheap enough to use
 widely. egrep zsock_send *.c in malamute-core/src.

 * Locking on socketsL: we did in fact have a pull request for this
 once. It was... nasty. We reverted it. We breathed a sigh of relief.
 However looking back, the problem was valid and has never been solved
 since.

 * If you're doing multipart a lot in an application, you can replace
 that with zproto. You already have contracts then, why not make them
 explicit and documented? That's always a win in my experience.

 * Multi-hop request reply is a strange beast and I'm keen to
 understand those architectures that use it. My suspicion is that we've
 shifted our vision of what ZeroMQ is over the years. My own
 experience seems plausible, yet I distrust it. So, the stories in my
 article are please for falsification, not attempts to convince.

 * I think we have learned to not break existing code. It's going to be
 interesting to run multiple models at once. We do this in CZMQ and it
 works OK. There isn't much overhead.

 * Authentication and routing information should be (MUST be) two
 totally separate layers. CURVE certainly does not use the routing ID
 (even if it's still misnamed as IDENTITY). You can have the same
 client on N connections (obviously). You authenticate a client using a
 mechanism-specific key: PLAIN user id, or CURVE public key.

 -Pieter
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

Some observations on adding a discrete router_id field to the message -

Depending on alignment, this reduces the size of a VSM message by 4 or 8
bytes.

Does this field really need to be a member of the union? Currently
msg_t::file_desc is 64 bit to force alignment, but FDs are 32bit values
(even on Windows, where the FD is 64 bits, it will never give values 
2^32). Could we not just pack these two together, and make use of the
currently unused bits? It gets rid of the combinatorial expansion of adding
fields to each member of the union (at least for this case).

On Mon, Feb 2, 2015 at 1:06 PM, Doron Somech somdo...@gmail.com wrote:

 Brian -

 The issue is that with the new api and to enable thread safety the routing
 id is part of the message. So czmq new api should somehow expose routing id
 on the message and/or part of the send message.
 On Feb 2, 2015 7:39 PM, Brian Knox bk...@digitalocean.com wrote:

 Doron -

 I did a test implementation around this idea in goczmq today and I'm
 liking the semantics.  I wrote an interface that conforms to io.Reader and
 io.Writer where you pass a call a byte buffer and you get the message
 placed into it.

 When the socket is a router socket, it silently drops the ID frame under
 the hood, but sets a lastClientID in the socket struct, that if you need,
 you can get with a GetLastClientID call.

 For reference:

 https://github.com/zeromq/goczmq/blob/master/sock.go#L35 (note strings
 in go are just immutable byte arrays)

 https://github.com/zeromq/goczmq/blob/master/sock.go#L333

 https://github.com/zeromq/goczmq/blob/master/sock.go#L366

 So if the socket is a router, the Write call just transparently uses the
 lastClientID value.  In a one to one request / reply, you then don't need
 to think about it at all, and if you need to do async work, you can get and
 set the id as needed.

 I'll just move this to use the new API later - just wanted to try it out
 and see how I liked it, and I say thumbs up to dropping frames on the new
 Server / Client sockets.



 On Mon, Feb 2, 2015 at 4:37 PM, Doron Somech somdo...@gmail.com wrote:

 So the new sockets are in the github master, you can take a loot at the
 test to see how to use the new routing id field:

 https://github.com/zeromq/libzmq/blob/master/tests/test_client_server.cpp

 Few of the reasons I didn't like multi frames:
 * I tried in the past to make both zeromq and NetMQ thread safe, think
 of sending from multiple threads or receiving from multiple threads. we
 cannot do that with Multipart.
 * There are a lot of good transport that already implement message
 framing (UDP, WebSockets, SCTP and even HTTP), but because zeromq required
 it is own framing it was not easy to add them.
 * Multipart, router usage (routing id frame) and not being thread safe
 make the learning curve of zeromq hard to beginners. Without three of them
 zeromq become much simpler.
 * At least with NetMQ single part message is much faster than multipart.
 * New stacks, multipart is complicated to implement, with the new API it
 will much more easier to implement new stacks (like JSMQ) or any native
 stack.

 Pieter I'm looking forward to see how you expose the routing id in the
 czmq API.
 I also like the czmq API for sending mutlipart messages (the picture
 feature) so maybe we can use that to generate single frame which is also
 compatible with zproto.

 About the implementation, none of new sockets support any option now.
 server behave like mandatory router, so when router is not reachable or
 highwater mark is reached an error will be returned.

 As ZMTP 3.1 is still in raw status, what do you think of removing the
 multipart from it? maybe the 3.1 will only support the new socket types.

 Anyway I really excited about this change.





 On Mon, Feb 2, 2015 at 4:17 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 What we really want IMO is per-peer metadata, and an API to get/set
 this. Using messages is a hack.


 Currently working on that :)

 Having two layers that both
 carry per-message data is... wrong IMO.


 Protocols supporting 'out of band' data aren't exactly uncommon.

 However the key thing is, what's the problem. Then we can discuss
 solutions to that.


 I don't have an immediate use-case justifying it. I noted it, mostly
 because it has come up a few times since I started paying attention.

 On Mon, Feb 2, 2015 at 7:55 AM, Pieter Hintjens p...@imatix.com wrote:

  It seems to me that in order to remove multi-part messages and
 introduce new
  socket types (e.g. SERVER/CLIENT) that would
  necessitate a revision of the wire protocol. If we are going to do
 that, it
  might be worth considering per-message
  metadata -

 We'd have to be very clear about the problem that per-message metadata
 is aiming for. There is an elegance to delivering blobs and nothing
 more. Metadata can be added on top using zproto.

 What we really want IMO is per-peer metadata, and an API to get/set
 this. Using messages is a hack. If we

Re: [zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

My eventual suggestion was to look at using metadata for this, it is
already there and is per-connection. But there are (currently) a few
problems with using it this way and I wanted to think those through a bit
before making the suggestion.

I am not sure why file_desc was placed where it is.

On Mon, Feb 2, 2015 at 2:25 PM, Doron Somech somdo...@gmail.com wrote:

 Currently the router_id is in the last 4 bytes of the 64 bytes message
 size, could this cause alignment issue?

 Regarding the idea to combine it with the file descriptor, I think it can
 cause portability issues in the future, but it might be platform specific.

 Why wasn't it originally in end of the union which can solve the alignment
 issue?

 Anyway in the future we might not need it, because we can query the socket
 with the routing id to get metadata.

 On Mon, Feb 2, 2015 at 10:02 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 Some observations on adding a discrete router_id field to the message -

 Depending on alignment, this reduces the size of a VSM message by 4 or 8
 bytes.

 Does this field really need to be a member of the union? Currently
 msg_t::file_desc is 64 bit to force alignment, but FDs are 32bit values
 (even on Windows, where the FD is 64 bits, it will never give values 
 2^32). Could we not just pack these two together, and make use of the
 currently unused bits? It gets rid of the combinatorial expansion of adding
 fields to each member of the union (at least for this case).

 On Mon, Feb 2, 2015 at 1:06 PM, Doron Somech somdo...@gmail.com wrote:

 Brian -

 The issue is that with the new api and to enable thread safety the
 routing id is part of the message. So czmq new api should somehow expose
 routing id on the message and/or part of the send message.
 On Feb 2, 2015 7:39 PM, Brian Knox bk...@digitalocean.com wrote:

 Doron -

 I did a test implementation around this idea in goczmq today and I'm
 liking the semantics.  I wrote an interface that conforms to io.Reader and
 io.Writer where you pass a call a byte buffer and you get the message
 placed into it.

 When the socket is a router socket, it silently drops the ID frame
 under the hood, but sets a lastClientID in the socket struct, that if you
 need, you can get with a GetLastClientID call.

 For reference:

 https://github.com/zeromq/goczmq/blob/master/sock.go#L35 (note
 strings in go are just immutable byte arrays)

 https://github.com/zeromq/goczmq/blob/master/sock.go#L333

 https://github.com/zeromq/goczmq/blob/master/sock.go#L366

 So if the socket is a router, the Write call just transparently uses
 the lastClientID value.  In a one to one request / reply, you then don't
 need to think about it at all, and if you need to do async work, you can
 get and set the id as needed.

 I'll just move this to use the new API later - just wanted to try it
 out and see how I liked it, and I say thumbs up to dropping frames on the
 new Server / Client sockets.



 On Mon, Feb 2, 2015 at 4:37 PM, Doron Somech somdo...@gmail.com
 wrote:

 So the new sockets are in the github master, you can take a loot at
 the test to see how to use the new routing id field:


 https://github.com/zeromq/libzmq/blob/master/tests/test_client_server.cpp

 Few of the reasons I didn't like multi frames:
 * I tried in the past to make both zeromq and NetMQ thread safe, think
 of sending from multiple threads or receiving from multiple threads. we
 cannot do that with Multipart.
 * There are a lot of good transport that already implement message
 framing (UDP, WebSockets, SCTP and even HTTP), but because zeromq required
 it is own framing it was not easy to add them.
 * Multipart, router usage (routing id frame) and not being thread safe
 make the learning curve of zeromq hard to beginners. Without three of them
 zeromq become much simpler.
 * At least with NetMQ single part message is much faster than
 multipart.
 * New stacks, multipart is complicated to implement, with the new API
 it will much more easier to implement new stacks (like JSMQ) or any native
 stack.

 Pieter I'm looking forward to see how you expose the routing id in the
 czmq API.
 I also like the czmq API for sending mutlipart messages (the picture
 feature) so maybe we can use that to generate single frame which is also
 compatible with zproto.

 About the implementation, none of new sockets support any option now.
 server behave like mandatory router, so when router is not reachable or
 highwater mark is reached an error will be returned.

 As ZMTP 3.1 is still in raw status, what do you think of removing the
 multipart from it? maybe the 3.1 will only support the new socket types.

 Anyway I really excited about this change.





 On Mon, Feb 2, 2015 at 4:17 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:

 What we really want IMO is per-peer metadata, and an API to get/set
 this. Using messages is a hack.


 Currently working on that :)

 Having two layers that both
 carry per-message data is... wrong IMO

Re: [zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

 - deprecate REQ and REP


It would seem, given their limited utility, that marking these DEPRECATED
in the next version of libzmq would be an easy step to take.

It seems to me that in order to remove multi-part messages and introduce
new socket types (e.g. SERVER/CLIENT) that would
necessitate a revision of the wire protocol. If we are going to do that, it
might be worth considering per-message
metadata -

* There have been at least a few questions/requests in this direction, the
wire protocol doesn't support it.
* The metadata would have the same basic wire format as connection
metadata, and read as part of a single message.
* It might serve to eliminate some uses of multi-part messages without
resorting to some form of in-message framing.


On Mon, Feb 2, 2015 at 3:23 AM, Pieter Hintjens p...@imatix.com wrote:

 Hi folks,

 We had an interesting pre-FOSDEM hackathon on Thursday and Friday, in
 Brussels.

 One of the threads that came out, thanks mainly to Doron Somech
 (NetMQ) was a strategy for simplifying ZeroMQ. This started as a
 discussion of Nanomsg's dropping of multipart messages.

 Overall, multipart messages add a lot of complexity and confusion to
 the library and bindings. In case we forget:

 - frame vs, message vs. part
 - routing id frames
 - request-reply envelopes
 - router sockets
 - identities

 Multipart messages are the main reason we can't make threadsafe sockets.

 So, we're going to experiment with shifting ZeroMQ (libzmq, NetMQ,
 CZMQ, and other bindings) in this direction:

 - deprecate multipart messages from the API - when we need framing, we
 can use zproto
 - deprecate ROUTER and DEALER and slowly replace with SERVER / CLIENT
 sockets that refuse multipart data
 - deprecate REQ and REP
 - SERVER has get/set routing ID on message
 - routing ID is an integer
 - routing ID cannot be set by peer, so we deprecate ZMQ_IDENTITY
 - start to aim for threadsafe sockets
 - deprecate the ability to build request-reply chains

 ...

 This is not a roadmap, nor is this a proposal, it's just a realization
 by several of us that multipart messages create complexity, which we
 dislike, and which causes cost and irritation.

 Cheers
 Pieter
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Notes from a hackathon

[Thomas Rodgers]

 What we really want IMO is per-peer metadata, and an API to get/set
 this. Using messages is a hack.


Currently working on that :)

Having two layers that both
 carry per-message data is... wrong IMO.


Protocols supporting 'out of band' data aren't exactly uncommon.

However the key thing is, what's the problem. Then we can discuss
 solutions to that.


I don't have an immediate use-case justifying it. I noted it, mostly
because it has come up a few times since I started paying attention.

On Mon, Feb 2, 2015 at 7:55 AM, Pieter Hintjens p...@imatix.com wrote:

  It seems to me that in order to remove multi-part messages and introduce
 new
  socket types (e.g. SERVER/CLIENT) that would
  necessitate a revision of the wire protocol. If we are going to do that,
 it
  might be worth considering per-message
  metadata -

 We'd have to be very clear about the problem that per-message metadata
 is aiming for. There is an elegance to delivering blobs and nothing
 more. Metadata can be added on top using zproto.

 What we really want IMO is per-peer metadata, and an API to get/set
 this. Using messages is a hack. If we are sending/receiving data on a
 per-message basis, that is the message. Having two layers that both
 carry per-message data is... wrong IMO.

 However the key thing is, what's the problem. Then we can discuss
 solutions to that.

 -Pieter
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] libzmq - allocations, exceptions, alloc_assert and such

[Thomas Rodgers]

 To understand correctly, we don't propagate such failures (as
 exceptions or error returns), and even if we did, it'd be pointless...


My thinly veiled agenda here is -

We are already toast in this case anyway, can we just get rid of the extra
complexity that comes with trying pretend we can actually reliably do
something under a memory exhaustion case?



On Wed, Jan 28, 2015 at 1:07 PM, Pieter Hintjens p...@imatix.com wrote:

 To understand correctly, we don't propagate such failures (as
 exceptions or error returns), and even if we did, it'd be pointless...

 FWIW we added quite a lot handling in CZMQ to handle memory
 exhaustion. I don't particularly like that, as it makes things complex
 and it's unclear that there's any practical strategy for apps that hit
 such errors.


 On Tue, Jan 27, 2015 at 8:25 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:
  I know sustrik has previously railed on this topic, but at the risk of
  rehashing some of that ground...
 
  My reading of libzmq's source suggests that it goes to some lengths to
  prevent raising C++ exceptions, which, given that the C API functions do
 not
  attempt to guard against propagating exceptions to the caller, is a Good
  Thing. The code in some places uses malloc/free, in others either
 placement
  new into pre-allocated memory or new (std::nothrow) to prevent
 allocations
  from throwing. This is all well and good as far as it goes, but it
 doesn't
  go that far -
 
  stream_engine_t, mechanism_t, metadata_t, ctx_t (for example) all use
  node-based STL containers (std::map, std::mutlimap) which perform
  allocations on insertion/copy.
 
  mechanism_t's ctor default instantiates two std::mapstd::string,
  std::string's. Properties are then added to these dictionaries as they
 are
  consumed from the wire. Each property is stored as a key/value pair of
  std::string, which may throw on construction if it cannot allocate the
  requested space, and the insert may throw if it cannot allocate space for
  the map node.
 
  In stream_engine_t::mechanism_read() -
 
  It creates a local std::mapstd::string, std::string which it then
 merges
  properties exchanged from the transport mechanism (zap and zmtp) then
  constructs a metadata_t with a copy of that merged set. Though
 metadata_t is
  instantiated as follows -
 
  metadata = new (std::nothrow) metadata_t (properties);
 
  This can still throw. All std::nothrow guarantees is the allocation of
 space
  for metadata_t will not throw, it does not guard against metadata_t's
 ctor
  throwing (which can happen since it takes, and therefore must allocate
 space
  for, a copy of properties).
 
  This is perhaps somewhat academic since, in a low memory situation, you
 are
  likely hosed anyway (and on Linux you will likely never see an exception
  because of the OOM killer), but from a design standpoint the library
  currently has the ability to propagate errors back up the call stack to a
  client that can, in no way, do anything about them.
 
  Should the user facing API wrap and catch any propagated exceptions, and
  either return some error code or in the std::bad_alloc, do an
 alloc_assert
  and terminate?
 
  Another option that will address this case is to introduce a custom
  allocator which fails via alloc_assert, and update all STL type
 definitions
  to use that allocator.
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Open file leak during DNS resolution while network is down (regression in libzmq-4.1.0 and libzmq-master) #1302

[Thomas Rodgers]

Is it safe to close issue #1302
https://github.com/zeromq/libzmq/issues/1302 now?

On Wed, Jan 21, 2015 at 8:13 PM, Tomas Krajca to...@repositpower.com
wrote:

 Hi Thomas,

 I can't reproduce the error against the latest libzmq trunk either. It
 must have been fixed fairly recently because we tested this with the
 latest libzmq trunk as of Friday last week or whenever it was. I would
 be curious to see how it got fixed but I can't quite find the right commit.

 I'll do some more testing on this one but it seems good.

 Cheers,
 Tomas

 On 01/21/2015 10:00 PM, zeromq-dev-requ...@lists.zeromq.org wrote:
  I'm running your sample against current libzmq trunk, Ubuntu 14.04 and I
 am
  unable to reproduce any leak.
 
  On Tue, Jan 20, 2015 at 2:08 AM, Pieter Hintjensp...@imatix.com  wrote:
 
  OK, thanks for the simple test case.
  
  I'm not familiar enough with the internals of libzmq to debug this. I
  see that tcp_connecter.cpp is closing the socket if it can't resolve
  the hostname. However it's possible some error handling isn't right
  here.
  
  
  On Tue, Jan 20, 2015 at 5:04 AM, Tomas Krajcato...@repositpower.com
  wrote:
   Hi Peter,
   
   It's actually really simple, I have posted example C code to github
 at
   https://github.com/zeromq/libzmq/issues/1302. Am I doing something
 wrong
   or is it that obvious?
   
   There is no need for a poller or anything like that. It seems that
 DNS
   resolution during zmq_connect() somehow does not release the file
 handle
   if network is down.
   
   Cheers,
   Tomas
   
   Message: 19
   Date: Mon, 19 Jan 2015 10:32:47 +0100
   From: Pieter Hintjensp...@imatix.com
   Subject: Re: [zeromq-dev] Open file leak during DNS resolution
 while
  network is down (regression in libzmq-4.1.0 and
 libzmq-master)
  #1302
   To: ZeroMQ development listzeromq-dev@lists.zeromq.org
   Cc: Mark Burgessm...@repositpower.com
   Message-ID:
  CADL5_shw3B+0YN4MYVCROEwufeH6_ThvxDKcw5c=
  vkfo4dw...@mail.gmail.com
   Content-Type: text/plain; charset=UTF-8
   
   Can your C++ programmer make a minimal test case in C that
 reproduces
   the problem?
   
   On Mon, Jan 19, 2015 at 1:55 AM, Tomas Krajca
 to...@repositpower.com
  wrote:
   Hi,
   
   I've reported this weird bug
  https://github.com/zeromq/libzmq/issues/1302
   that we hit last week, I wonder if anybody experienced the same
 thing
  or can
   reproduce it. Basically, we saw a progressive file handle leak
 that
  crashed
   our application after about an hour of network outage.
   
   Any thoughts of which part of the code could the bug be in?
 We've got
  a C++
   programmer in our team but don't know enough about libzmq
 internals to
  try
   to fix this.
   
   Thanks,
   Tomas
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Correct behavior for closing messages after pipe::write in libzmq

[Thomas Rodgers]

I've recently been looking at msg_t and metadata_t and the general lifetime
management issues around them.

zmq::msg_t is, in some sense, not a proper C++ class, in that while it
happily possesses all of the compiler generated default operations (default
ctor, copy ctor, default dtor, default assignment operator), none of it's
internals actually participate in ordinary C++ lifetime rules. I understand
the intention behind why msg_t works the way it does; you really do want
these things to have stack duration for small message sizes from an
efficiency standpoint, and you want the type to be opaque to the library
user.

Unfortunately, this has created problems
https://github.com/zeromq/libzmq/issues/1058 before, with messages being
pushed onto a ypipe, and the internals of the message type not properly
participating in the invocation of operator=().

Because of this design, it is necessary for every single piece of code that
deals with msg_t to be aware of the lifecycle requirements of it's internal
state. In some case, the body has been passed off to some other code that
now 'owns' it, so it is ok to call init() on your local msg_t. In other
cases, you are the 'owner', and it is your responsibility to call close.

This to me seems messy and is only going to get worse with time (things get
added, memories get fuzzy, those that knew what was supposed to happen move
on, etc.).

I don't know if it is possible at this point to 'fix' this in any sort of
sane way, but I'm currently working on an experiment to see if the code can
be modified in such a way that C++'s normal lifetime semantics 'just work',
and the public API would still treat these as opaque stack local types and
work the way it always has from the user's perspective.

On Tue, Jan 20, 2015 at 4:49 PM, Topher Brown topher...@gmail.com wrote:

 I recently tracked down a memory leak of the message memory buffer related
 to disconnecting sockets. Github issue here:
 https://github.com/zeromq/libzmq/issues/1313

 The problem stemmed from not calling msg::close on a message that fails to
 write to the pipe. While researching through the code I noticed
 inconsistencies in how this scenario is handled, and I was hoping to come
 to some kind of consencious on how to handle this issue.

 My patch (https://github.com/zeromq/libzmq/pull/1314) only dealt with
 cleaning up messages in router::xsend. However, the code in stream::xsend
 looks nearly identical. Should it have the same fix? I have not done so
 myself because I have no code that runs that function, although it is
 pretty clear to me it should receive a similar patch.

 The underlying question: when should msg::close be called? Should
 msg::close be called after ALL calls to pipe::write (even successful ones)?
 It looks like xsub::send_subscription uses the same paradigm as I
 discovered with my patch (call msg::close only after failed pipe::write).
 However router::xattach_pipe and dealer::xattach_pipe take the path of
 msg::close in all cases (even on pipe::write success!).

 Can we kick this problem back up the stack? Should pipe::write call
 msg::close if it knows it is returning false (I think no)? How about this
 then - should msg::init call msg::close on itself before resetting its
 metadata? That would mitigate this issue and others like it, and can act as
 a failsafe for not cleaning up messages properly in other places. After
 all: who best to make sure messages are cleaned up than the message class
 itself?

 I'm hesitant to make these changes myself because I have only experienced
 the one memory leak and I'm not super familiar with the libzmq internals.
 I'd love to get guidance on the best way forward. I think at a minimum
 stream::xsend should get a similar patch to mine to ensure non-sent
 messages are closed properly. If people think it's a good idea, I'd be
 happy to make a patch ensuring msg::close has been called in msg::init as
 well.

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

[Thomas Rodgers]

Do you see the same behavior if you replace C with fopen() ?

On Tue, Jan 20, 2015 at 7:40 AM, Olaf Mandel o.man...@menlosystems.com
wrote:

 Am 20.01.2015 14:35, schrieb Olaf Mandel:
 -Snipp-
 
 
  #include sys/ioctl.h
  #include zmq.hpp
 -Snipp-

 Shoot: That was missing a few include statements at the top the program
 and the compile instructions. Correct start of the demo program:


 /*
  *  Compile with:
  *  g++ -Wall -Werror -Wextra -o test test.cpp -lzmq
  */
 #include fcntl.h
 #include fstream
 #include iostream
 #include linux/spi/spidev.h
 #include sys/ioctl.h
 #include zmq.hpp


 Sorry about that,
 Olaf Mandel
 --
 Olaf Mandel
 phone: +49-89-189166-250
 fax:   +49-89-189166-111
 Menlo Systems GmbH
 Am Klopferspitz 19a, D-82152 Martinsried
 Amtsgericht München HRB 138145
 Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth
 USt-IdNr. DE217772017, St.-Nr. 14316170324


 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Open file leak during DNS resolution while network is down (regression in libzmq-4.1.0 and libzmq-master) #1302

[Thomas Rodgers]

I'm running your sample against current libzmq trunk, Ubuntu 14.04 and I am
unable to reproduce any leak.

On Tue, Jan 20, 2015 at 2:08 AM, Pieter Hintjens p...@imatix.com wrote:

 OK, thanks for the simple test case.

 I'm not familiar enough with the internals of libzmq to debug this. I
 see that tcp_connecter.cpp is closing the socket if it can't resolve
 the hostname. However it's possible some error handling isn't right
 here.


 On Tue, Jan 20, 2015 at 5:04 AM, Tomas Krajca to...@repositpower.com
 wrote:
  Hi Peter,
 
  It's actually really simple, I have posted example C code to github at
  https://github.com/zeromq/libzmq/issues/1302. Am I doing something wrong
  or is it that obvious?
 
  There is no need for a poller or anything like that. It seems that DNS
  resolution during zmq_connect() somehow does not release the file handle
  if network is down.
 
  Cheers,
  Tomas
 
  Message: 19
  Date: Mon, 19 Jan 2015 10:32:47 +0100
  From: Pieter Hintjens p...@imatix.com
  Subject: Re: [zeromq-dev] Open file leak during DNS resolution while
network is down (regression in libzmq-4.1.0 and libzmq-master)
 #1302
  To: ZeroMQ development list zeromq-dev@lists.zeromq.org
  Cc: Mark Burgess m...@repositpower.com
  Message-ID:
CADL5_shw3B+0YN4MYVCROEwufeH6_ThvxDKcw5c=
 vkfo4dw...@mail.gmail.com
  Content-Type: text/plain; charset=UTF-8
 
  Can your C++ programmer make a minimal test case in C that reproduces
  the problem?
 
  On Mon, Jan 19, 2015 at 1:55 AM, Tomas Krajca to...@repositpower.com
 wrote:
  Hi,
 
  I've reported this weird bug
 https://github.com/zeromq/libzmq/issues/1302
  that we hit last week, I wonder if anybody experienced the same thing
 or can
  reproduce it. Basically, we saw a progressive file handle leak that
 crashed
  our application after about an hour of network outage.
 
  Any thoughts of which part of the code could the bug be in? We've got
 a C++
  programmer in our team but don't know enough about libzmq internals to
 try
  to fix this.
 
  Thanks,
  Tomas
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

[Thomas Rodgers]

No, not really. libc++ doesn't do anything particularly interesting with
fd's but I just wanted to formally rule it out.
Unfortunately I don't have a system (or any experience dealing) with SPI
devices. I don't think libzmq does anything particularly 'funky' with any
of the file descriptors it manages though (at least based on my reading of
the source).

On Tue, Jan 20, 2015 at 8:56 AM, Olaf Mandel o.man...@menlosystems.com
wrote:

 Hello Thomas,

 thank you for the quick answer.

 Am 20.01.2015 15:11, schrieb Thomas Rodgers:
  Do you see the same behavior if you replace C with fopen() ?
 -Snipp-

 Not quite: if the error occurs, the behaviour is the same as before. But
 now the error _always_ happens: closing the file descriptor in the C
 version of the test makes no difference. New test below:


 /*
  *  Compile with:
  *  g++ -Wall -Werror -Wextra -pedantic -x c -o test test.c -lzmq
  */
 #include fcntl.h
 #include linux/spi/spidev.h
 #include stdio.h
 #include string.h
 #include sys/ioctl.h
 #include zmq.h


 /*#define ADDR tcp://127.0.0.1:8000*/
 #define ADDR inproc://addr


 /*
  *  The program always shows the problem (independent of the presence
  *  of D) for the following permutations of the blocks:
  *  - A B C D
  *  - A C B D
  *  - A C D B
  *  - C A B D
  *  - C A D B
  *  - C D A B
  *
  *  With the constraint that A must be before B and C before D, there
  *  are no further valid permutations.
  *
  *  For the TCP address, the error message is: No such device
  *  For the inproc address, it is: Resource temporarily unavailable
  */
 int main()
 {
 void*  ctx;
 void*  skt;
 FILE*  f;
 intfd;
 struct spi_ioc_transfer pcks;

 ctx = zmq_ctx_new();/* A */

 skt = zmq_socket(ctx, ZMQ_PUB); /* B */
 zmq_bind(skt, ADDR);

 f = fopen(log, w);  /* C */
 (void)sizeof(f);

 fclose(f);  /* D */

 /* The following always last */
 fd = open(/dev/spidev32766.0, O_RDWR);
 memset(pcks, 0, sizeof(struct spi_ioc_transfer));
 ioctl(fd, SPI_IOC_MESSAGE(1), pcks);
 printf(errno: %s\n, strerror(errno));

 return 0;
 }


 The one advantage of this is: I now at least can see the FILE structure
 and the contained _fileno member.

 Any further thoughts?
 Olaf Mandel
 --
 Olaf Mandel
 phone: +49-89-189166-250
 fax:   +49-89-189166-111
 Menlo Systems GmbH
 Am Klopferspitz 19a, D-82152 Martinsried
 Amtsgericht München HRB 138145
 Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth
 USt-IdNr. DE217772017, St.-Nr. 14316170324


 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

[Thomas Rodgers]

 At least in the C++ version, the problem is relatively fragile


 I always see the problem in my pure-C test


There are those that maintain that C is a simpler and more robust language
than C++ :-)~

On Tue, Jan 20, 2015 at 11:32 AM, Olaf Mandel o.man...@menlosystems.com
wrote:

 Hello,

 Am 20.01.2015 18:07, schrieb Arnaud Kapp:
  I don't really see anything in the small example that could cause a bug.
  I am myself using libzmq (with zmqpp as a wrapper) on a Raspberry Pi +
  a Piface digital card (which is a SPI device), and I have no trouble.
 
 At least in the C++ version, the problem is relatively fragile: it only
 occurs if mixing ZMQ socket operations binds/connects with opening and
 closing files. There are cases where I also don't see the problem.
 Weirdly, I always see the problem in my pure-C test...

  My kernel version is 3.12.28+ and I use a recent (a few commits behind
  HEAD) version of libzmq.
 -Snipp-

 Good point, my machine and version numbers are:

 CPU:   Freescale i.MX537 (Cortex-A8, NEON)
 GCC:   4.8.1, cross-compiling
 Linux: 3.10.28 + many platform patches
 ZMQ:   zeromq/libzmq.git @ be23e699c

 Any other info of interest?

 Best regards,
 Olaf Mandel
 --
 Olaf Mandel
 phone: +49-89-189166-250
 fax:   +49-89-189166-111
 Menlo Systems GmbH
 Am Klopferspitz 19a, D-82152 Martinsried
 Amtsgericht München HRB 138145
 Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth
 USt-IdNr. DE217772017, St.-Nr. 14316170324


 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] proposal: add metadata property Remote-Endpoint

[Thomas Rodgers]

See https://github.com/zeromq/libzmq/pull/1309

Property name is Peer-Address since this mirrors the stream_engine member
name used as the source data for the property.

On Thu, Jan 15, 2015 at 6:43 AM, Peter Kleiweg pklei...@xs4all.nl wrote:


 Proposal:

 zmq_msg_gets(message, Remote-Endpoint) should return the IP
 address of the remote endpoint.

 This in place of, or as addition to zmq_msg_get(message, ZMQ_SRCFD)

 This way, non-C programmers don't have to include C code to
 determine the remote IP address for the socket fd.

 (What other use for ZMQ_SRCFD is there?)

 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl/
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

[Thomas Rodgers]

  I'm also fine just marking deprecated and reverting my size check change.

 No don't do this! Preventing memory corruption can only be a good thing.


I agree, but basically makes it completely unusable in certain use cases
(as you so eloquently put it, this option is 'weird').

Anyway, unless there is strong consensus for deprecation, I am going to
unwind the whole thing.

On Fri, Jan 9, 2015 at 12:13 PM, Arnaud Kapp kapp.a...@gmail.com wrote:

  I'm also fine just marking deprecated and reverting my size check change.

 No don't do this! Preventing memory corruption can only be a good thing.

  It wasn't part of any release (except pre-release).

 Oh I didn't realize it was that new.
 Well in that case, if we're going to remove it we might as well do it
 now indeed.

 On Fri, Jan 9, 2015 at 7:07 PM, Peter Kleiweg pklei...@xs4all.nl wrote:
  Arnaud Kapp schreef op de 9e dag van de louwmaand van het jaar 2015:
 
  Hello,
 
  I agree that this option is weird, and it's behavior not properly
  defined (the fd_t stuff).
  However, shouldn't we mark this option as deprecated instead, and
  remove it in a later version?
 
  It wasn't part of any release (except pre-release).
 
 
 
 
  --
  Peter Kleiweg
  http://pkleiweg.home.xs4all.nl/
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev



 --
 Kapp Arnaud - Xaqq
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

[Thomas Rodgers]

Excellent, I submitted issue 1296
https://github.com/zeromq/libzmq/issues/1296 to capture it. I will put
together the pull req over the weekend.

On Fri, Jan 9, 2015 at 11:26 AM, Pieter Hintjens p...@imatix.com wrote:

 Sounds good.

 On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:
  I would like to propose removing this option before it becomes part of an
  officially released API, but I would like to reassurance that this is an
  appropriate course of action before doing so.
 
  My reasoning for removing it is as follows -
 
  * It is the only option to zmq_getsockopt() that treats option_value as a
  value/result parameter, all others treat option_value as strictly a
 result
  parameter.
 
  * A brief survey of the Posix getsockopt() API shows a similar lack of
 using
  option_value as a value/result parameter.
 
  * The original implementation requires the caller to ensure that the
  returned buffer is sufficient to hold an fd_t, but fd_t is not part of
  ZeroMQ's public API. It is conditionally defined by platform and on
 Windows
  has two potential definitions.
 
  * I'm not comfortable with this blind faith assignment through a
 pointer, so
  I submitted a length check change. Unfortunately this introduces a whole
 new
  class of potential usage problems for this option.
 
  * I don't know what the intended use case for the option is, but I infer
  from the test_id2fd test case, that is to build a map of router identity
 to
  fd, perhaps to pass fd to getpeername(2) and build a map of identity to
  peername. If this is indeed the case, this use case is already handled by
  calling zmq_msg_get(part, ZMQ_SRCFD), on the message part containing the
  identity frame.
 
  What am I missing here?
 
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

[Thomas Rodgers]

I would like to propose removing this option before it becomes part of an
officially released API, but I would like to reassurance that this is an
appropriate course of action before doing so.

My reasoning for removing it is as follows -

* It is the only option to zmq_getsockopt() that treats option_value as a
value/result parameter, all others treat option_value as strictly a result
parameter.

* A brief survey of the Posix getsockopt() API shows a similar lack of
using option_value as a value/result parameter.

* The original implementation requires the caller to ensure that the
returned buffer is sufficient to hold an fd_t, but fd_t is not part of
ZeroMQ's public API. It is conditionally defined by platform and on Windows
has two potential definitions.

* I'm not comfortable with this blind faith assignment through a pointer,
so I submitted a length check change. Unfortunately this introduces a whole
new class of potential usage problems for this option.

* I don't know what the intended use case for the option is, but I infer
from the test_id2fd test case, that is to build a map of router identity to
fd, perhaps to pass fd to getpeername(2) and build a map of identity to
peername. If this is indeed the case, this use case is already handled by
calling zmq_msg_get(part, ZMQ_SRCFD), on the message part containing the
identity frame.

What am I missing here?
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

[Thomas Rodgers]

I guess my question is, since 4.1 hasn't been 'released' and is still an
rc, can we just avoid the potential downstream heartache all together and
remove it?

I'm also fine just marking deprecated and reverting my size check change.

On Fri, Jan 9, 2015 at 12:02 PM, Arnaud Kapp kapp.a...@gmail.com wrote:

 Hello,

 I agree that this option is weird, and it's behavior not properly
 defined (the fd_t stuff).
 However, shouldn't we mark this option as deprecated instead, and
 remove it in a later version?

 On Fri, Jan 9, 2015 at 6:43 PM, Pieter Hintjens p...@imatix.com wrote:
  Great :-)
 
  On Fri, Jan 9, 2015 at 6:38 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:
  Excellent, I submitted issue 1296 to capture it. I will put together the
  pull req over the weekend.
 
  On Fri, Jan 9, 2015 at 11:26 AM, Pieter Hintjens p...@imatix.com wrote:
 
  Sounds good.
 
  On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodgers rodg...@twrodgers.com
  wrote:
   I would like to propose removing this option before it becomes part
 of
   an
   officially released API, but I would like to reassurance that this
 is an
   appropriate course of action before doing so.
  
   My reasoning for removing it is as follows -
  
   * It is the only option to zmq_getsockopt() that treats option_value
 as
   a
   value/result parameter, all others treat option_value as strictly a
   result
   parameter.
  
   * A brief survey of the Posix getsockopt() API shows a similar lack
 of
   using
   option_value as a value/result parameter.
  
   * The original implementation requires the caller to ensure that the
   returned buffer is sufficient to hold an fd_t, but fd_t is not part
 of
   ZeroMQ's public API. It is conditionally defined by platform and on
   Windows
   has two potential definitions.
  
   * I'm not comfortable with this blind faith assignment through a
   pointer, so
   I submitted a length check change. Unfortunately this introduces a
 whole
   new
   class of potential usage problems for this option.
  
   * I don't know what the intended use case for the option is, but I
 infer
   from the test_id2fd test case, that is to build a map of router
 identity
   to
   fd, perhaps to pass fd to getpeername(2) and build a map of identity
 to
   peername. If this is indeed the case, this use case is already
 handled
   by
   calling zmq_msg_get(part, ZMQ_SRCFD), on the message part containing
   the
   identity frame.
  
   What am I missing here?
  
  
   ___
   zeromq-dev mailing list
   zeromq-dev@lists.zeromq.org
   http://lists.zeromq.org/mailman/listinfo/zeromq-dev
  
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev



 --
 Kapp Arnaud - Xaqq
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] lost message due to EINTR

[Thomas Rodgers]

Just a guess, are any watchpoints set in the debugging session?

On Friday, January 9, 2015, sven.koebn...@t-online.de wrote:

  I get that error only during debuging inside Eclipse C++ (gdb).

 It seems irrelevant, if there are breakpoints set or not (but if there are
 any breakpoints, that stop the program, the number of EINTR is
 significantly higher).

 I also wonder about getting EINTR because of a debugger. Thet is no Ctrl-C
 or else involved, the system is just running in debug mode under gdb when
 every 10th message during

 - send()

 - recv() in dispatcher

 - resend()ing in dispatcher to final receipient

 - recv() in receipient thread (or also, if I configure it to be a separate
 process)

 - and the same way back.

 So counting the send()s and recv()s, every 80th to 100th message is
 involved in an EINTR when debugging.

 If you know, what else causes EINTRs beside Ctrl-C and likewise, just tell
 me ... I just don't know. Using ZMQ2, I NEVER had EINTR, even if single
 stepping the application.



 Didn't you ever happen to get EINTR in your own testing? Maybe I still
 have undiscovered memory violations, that cause disruption of ZMQ-data and
 -threads, but the system acts identically, when I configure each Service
 Worker to be it's own process instead of just pthread()ing. So I assume,
 there shouldn't be too many hidden SEGVs, that disturb ZMQ.



 Creating an easy example is difficult, because we are highly parallel with
 (in debugging) about 30 own threads and lots more for ZMQ. The whole thing
 has about 12K Lines now when counting the rudimentary base system without
 counting code for what the application is meant to do.



 Am 2015-01-09 13:06, schrieb Pieter Hintjens:

 In theory you cannot get an error between frames. Also, EINTR means
 the process is shutting down, so the benefit of retrying seems vague.

 Can you provide a reproducible test case? I do not like discussing
 abstracts we cannot actually disprove.

 On Fri, Jan 9, 2015 at 12:08 PM,  sven.koebn...@t-online.de 
 javascript:_e(%7B%7D,'cvml','sven.koebn...@t-online.de'); wrote:

 the referenced fix should work for zmsg_send() but the same bug is in
 zmsg_recv() and there the application does not (yet) have any data.
 zmsg_recv() destroyes properly received frames 1 to n-1 if receiving frame
 n failes. Since the data is ONLY inside ZMQ at this time, the application
 cannot handle this and frames 1 to n-1 are gone finally. I think it would
 be good to either a) retry receiving a frame on EINTR inside ZMQ's code or
 b) offer a kind of zmsg_recv_continue() that appends further frames to a
 message after a (partial) failure shouldn't zmq's higher level APIs
 conpletely handle EINTR on atomar (frame) basis? Am 2015-01-09 10:53,
 schrieb Pieter Hintjens: I've fixed the error in zmsg and in zframe, see
 https://github.com/zeromq/czmq/pull/886 On Fri, Jan 9, 2015 at 10:46 AM,
 Pieter Hintjens p...@imatix.com
 javascript:_e(%7B%7D,'cvml','p...@imatix.com'); wrote: Can you make a
 minimal reproducible test case? On Fri, Jan 9, 2015 at 9:41 AM, 
 sven.koebn...@t-online.de
 javascript:_e(%7B%7D,'cvml','sven.koebn...@t-online.de'); wrote:
 another related thing buthers me in this context: When zmsg_send() indeed
 returns with rc==-1 and a NULLed message (data is definitely lost) I have a
 chance to check for this lost message (simply asserting on rc==-1 
 message==NULL). BUT (!!) what is with zmsg_recv() ? Situation: I
 successfully zmsg_send() a message and is is delivered by ZMQ to the target
 (still inside ZMQ). When the same error occurs in the applications
 zmsg_recv() call, will the message be returned in the next call to
 zmsg_recv() or is is lost in this case also. Here, I do not have any chance
 to work with a copy as would be possible in the sending example below. This
 question destroys the first idea of holding a copy before sending. Indeed,
 I tryed, but zmsg_dup() destroyes routing information in the message, so it
 gets lost(silently) in transport failing to be adressed. Does
 zmq_msg_copy() work better and also copies the rotuing info? As an info:
 the EINTR thingy happens in Suse Linux on 32 and 64 bit using ZMQ4 (in any
 version) while debuging with Eclipse/gdb. I happens VERY often when
 breakpoints are triggered, but also (rarely) when the application is just
 running under gdb without any suspends due to breakpoints (breakpoints
 existing, but not hit). The system when pretty well for 2 years (!!!) under
 ZMQ2 and I have this problem only in ZMQ4 ... there has never been an EINTR
 under ZMQ2, so my code had to be heavily modified with loops for temporary
 failures with errno== EINTR or EAGAIN. ^5 Am 2015-01-09 08:30, schrieb
 sven.koebn...@t-online.de:
 javascript:_e(%7B%7D,'cvml','sven.koebn...@t-online.de:'); Hi * ! I
 recently switched from ZMQ2 (pretty old) to ZMQ 4 and since then have some
 problems in debugging with EINTR. Following code: do { rc = zmsg_send
 (zrep, clsocket_); if (rc0) { if (errno == EINTR || 

Re: [zeromq-dev] How to use zmq_getsockopt with option ZMQ_IDENTITY_FD

[Thomas Rodgers]

This is an oddball API choice (and there is a bug in the implementation),
in that option_value* is being used as both and input and an output
parameter.

The size you pass in must be be *at least* sizeof(fd_t) bytes, because it
will overwrite the supplied identity string with the resulting file
descriptor. The bug is, it does not check to see that the size of supplied
output is sufficient to hold sizeof(fd_t), so bad things (stack/heap
corruption) would happen if you actually passed option_len = 2.

On Thu, Jan 8, 2015 at 7:26 AM, Peter Kleiweg pklei...@xs4all.nl wrote:


 Suppose the identity string is only two bytes long, I pad with
 zeros to get a string of eight bytes. What should the value of
 option_len be, 2 or 8?


 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl/
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] How to use zmq_getsockopt with option ZMQ_IDENTITY_FD

[Thomas Rodgers]

yes.

using blob_t = std::basic_stringunsigned char;

char buf[8] = { 'f', 'o', 'o', 0, 0, 0, 0, 0 };
blob_t a(foo);
blob_t b(buf, 8);

assert(a == b); // fails

I think there is another issue with all of this. By default (IIRC) the
identity is 5 bytes, so on a 64 bit platform, the passed in identity would
never be sufficient to receive sizeof(fd_t) if fd_t was in fact defined as
a UINT_PTR. I don't have a Windows machine handy so I can't verify what
sizeof(SOCKET) returns, but as many of Window's 'handle' types are in fact
pointers, I suspect this might also be an issue when fd_t is typedef'd to
SOCKET. On Posix systems, it's fine.






On Thu, Jan 8, 2015 at 8:28 AM, Peter Kleiweg pklei...@xs4all.nl wrote:

 Thomas Rodgers schreef op de 8e dag van de louwmaand van het jaar 2015:

  This is an oddball API choice (and there is a bug in the implementation),
  in that option_value* is being used as both and input and an output
  parameter.
 
  The size you pass in must be be *at least* sizeof(fd_t) bytes, because it
  will overwrite the supplied identity string with the resulting file
  descriptor. The bug is, it does not check to see that the size of
 supplied
  output is sufficient to hold sizeof(fd_t), so bad things (stack/heap
  corruption) would happen if you actually passed option_len = 2.

 But option_len is used for retrieving the identity string:

 blob_t identity= blob_t((unsigned char*)optval_,*optvallen_);

 Won't I get a wrong 'blob' if I use option_len = 8?


 
  On Thu, Jan 8, 2015 at 7:26 AM, Peter Kleiweg pklei...@xs4all.nl
 wrote:
 
  
   Suppose the identity string is only two bytes long, I pad with
   zeros to get a string of eight bytes. What should the value of
   option_len be, 2 or 8?



 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl/
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] How to use zmq_getsockopt with option ZMQ_IDENTITY_FD

[Thomas Rodgers]

Sorry to keep flogging this particular horse, but in re-reading the docs
for this option as I'm trying to clean it up...

NB: _option_value_ must be always big  enough to hold sizeof(fd_t) bytes
no matter how small the identity length is.

There are few issues here -

Prior to commit 45c681
https://github.com/zeromq/libzmq/commit/45c68154460b5cc828cb7ac027e5407776bff2ca
there
was no validation that option_len was sufficient to hold sizeof(fd_t), so
in the 'no matter how small' case where the supplied identity length was
less than sizeof(fd_t), which is not something that is part of the public
API, so the user has to 'just know', you may get silent stack/heap
corruption.

With the the check, zmq_getsockopt(ZMQ_IDENTITY_FD, ...) will now return
EINVAL and set option_len to the minimum required size (I think this is
better than the risk of silent corruption). Now you have the following -

In the case where ZeroMQ assigns a default identity, it will have a length
of 5, and on a Posix system, the FD will be an int, sizeof(int)  5, things
are fine. On 64bit Windows however, sizeof(fd_t) = 8. If I set option_len
to 8 on call, but only have 5 bytes, the blob will be constructed with
whatever 8 bytes of data happen to be in option_value, which will then fail
to match a valid identity (std::string can contain any char, is not null
terminated). How would this option ever work in this case?

Now, say a *nix user calls zmq_setsockopt(ZMQ_IDENTITY, ...) and uses two
byte socket identities. You get the same problem trying to pass sizeof(int)
as option_len in that you create a bogus identity to check. How would this
option ever work in this case?

The only 'safe' option seems to be blindly assume that the caller passed
something at least 4 or 8 bytes long, as the code did prior to 45c681
https://github.com/zeromq/libzmq/commit/45c68154460b5cc828cb7ac027e5407776bff2ca,
but then there is NO check against buffer overrun. Default alignment would
likely save us most of the time here, but it makes my spider sense tingle
and if the caller for some reason passed a pointer into a packed struct,
they would not be happy with the result.



On Thu, Jan 8, 2015 at 9:16 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:

 yes.

 using blob_t = std::basic_stringunsigned char;

 char buf[8] = { 'f', 'o', 'o', 0, 0, 0, 0, 0 };
 blob_t a(foo);
 blob_t b(buf, 8);

 assert(a == b); // fails

 I think there is another issue with all of this. By default (IIRC) the
 identity is 5 bytes, so on a 64 bit platform, the passed in identity would
 never be sufficient to receive sizeof(fd_t) if fd_t was in fact defined as
 a UINT_PTR. I don't have a Windows machine handy so I can't verify what
 sizeof(SOCKET) returns, but as many of Window's 'handle' types are in fact
 pointers, I suspect this might also be an issue when fd_t is typedef'd to
 SOCKET. On Posix systems, it's fine.






 On Thu, Jan 8, 2015 at 8:28 AM, Peter Kleiweg pklei...@xs4all.nl wrote:

 Thomas Rodgers schreef op de 8e dag van de louwmaand van het jaar 2015:

  This is an oddball API choice (and there is a bug in the
 implementation),
  in that option_value* is being used as both and input and an output
  parameter.
 
  The size you pass in must be be *at least* sizeof(fd_t) bytes, because
 it
  will overwrite the supplied identity string with the resulting file
  descriptor. The bug is, it does not check to see that the size of
 supplied
  output is sufficient to hold sizeof(fd_t), so bad things (stack/heap
  corruption) would happen if you actually passed option_len = 2.

 But option_len is used for retrieving the identity string:

 blob_t identity= blob_t((unsigned char*)optval_,*optvallen_);

 Won't I get a wrong 'blob' if I use option_len = 8?


 
  On Thu, Jan 8, 2015 at 7:26 AM, Peter Kleiweg pklei...@xs4all.nl
 wrote:
 
  
   Suppose the identity string is only two bytes long, I pad with
   zeros to get a string of eight bytes. What should the value of
   option_len be, 2 or 8?



 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl/
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev



___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] C API changes for ZeroMQ 4.1.0

[Thomas Rodgers]

 Actually, it's even worse than that. For a standard install, I can use
 only one type per platform. It has to be either SOCKET or UINT_PTR on all
 Windows platforms.


I don't know why there are two different types used on Windows, but this
aspect of fd_t has been there since the initial commit by sustrik in 2009.
ZMQ_FD has this behavior already (and has been that way since 2009 as well).

For ZMQ_FD there is a clearly defined use case; the FD is passed off to
whatever platform event demultiplexor you happen to have (epoll, kqueues,
select), and so it must be the type the underlying platform uses for these
system calls. It is not clear to me what you can practically do with the
value returned from ZMQ_IDENTITY_FD except treat it opaquely (it certainly
is not safe to do raw socket IO calls with it I would expect).

On Wed, Jan 7, 2015 at 8:16 PM, Peter Kleiweg pklei...@xs4all.nl wrote:



 Peter Kleiweg pklei...@xs4all.nl schreef op 8 januari 2015 03:08:50 CET:
 
 
  Thomas Rodgers rodg...@twrodgers.com schreef op 8 januari 2015
  02:56:18 CET:
   FD ~= file descriptor.
  
   fd_t, the type this option actually returns, is conditionally
  defined
   to be
   int or SOCKET depending on platform, same as with ZMQ_FD. It is
   however,
   not the same FD that would be returned by the ZMQ_FD option (I
  believe
   it
   is the underlying TCP file descriptor or SOCKET in this case).
  
 
  I have looked to the source.
 
  On non-Windows, it is an int. No problem.
 
  On Windows, it is either a SOCKET or a UINT_PTR. This is impossible. I
  write a Go binding[1] based on the C API. I need to know what the type
  is on Windows, and the C header file doesn't tell.
 

 Actually, it's even worse than that. For a standard install, I can use
 only one type per platform. It has to be either SOCKET or UINT_PTR on all
 Windows platforms.


 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] C API changes for ZeroMQ 4.1.0

[Thomas Rodgers]

FD ~= file descriptor.

fd_t, the type this option actually returns, is conditionally defined to be
int or SOCKET depending on platform, same as with ZMQ_FD. It is however,
not the same FD that would be returned by the ZMQ_FD option (I believe it
is the underlying TCP file descriptor or SOCKET in this case).

I am *not* the author of this option, I don't know the intended use case
for it. Also, fd_t is an internal definition, not exposed in zmq.h so it
probably shouldn't 'leak' into the interface documentation. If these are
compelling enough deficiencies, perhaps filing a Github issue would be in
order?

On Wed, Jan 7, 2015 at 3:37 PM, Peter Kleiweg pklei...@xs4all.nl wrote:

 Thomas Rodgers schreef op de 7e dag van de louwmaand van het jaar 2015:

  
   ZMQ_IDENTITY_FD is get only?
 
 
  Yes, given a previously set socket identity (see ZMQ_IDENTITY in
  http://api.zeromq.org/4-1:zmq-setsockopt), it will return the FD of the
  socket associated with that identity.

 What is an FD? A file descriptor? What is an fd_t?

 There is an option ZMQ_FD that returns a file descriptor. That
 is int or SOCKET, for non-windows or windows. Is this similar?




 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl/
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] C API changes for ZeroMQ 4.1.0

[Thomas Rodgers]

 And if fd_t is internal to the C++ code, why is it used in the C API
 reference?


As I noted -


 Also, fd_t is an internal definition, not exposed in zmq.h so it probably
 shouldn't 'leak' into the interface documentation. If these are compelling
 enough deficiencies, *perhaps filing a Github issue would be in order*?


On Wed, Jan 7, 2015 at 8:08 PM, Peter Kleiweg pklei...@xs4all.nl wrote:



 Thomas Rodgers rodg...@twrodgers.com schreef op 8 januari 2015 02:56:18
 CET:
  FD ~= file descriptor.
 
  fd_t, the type this option actually returns, is conditionally defined
  to be
  int or SOCKET depending on platform, same as with ZMQ_FD. It is
  however,
  not the same FD that would be returned by the ZMQ_FD option (I believe
  it
  is the underlying TCP file descriptor or SOCKET in this case).
 

 I have looked to the source.

 On non-Windows, it is an int. No problem.

 On Windows, it is either a SOCKET or a UINT_PTR. This is impossible. I
 write a Go binding[1] based on the C API. I need to know what the type is
 on Windows, and the C header file doesn't tell.

 And if fd_t is internal to the C++ code, why is it used in the C API
 reference?


 [1] http://github.com/pebbe/zmq4

 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] C API changes for ZeroMQ 4.1.0

[Thomas Rodgers]

GSSAPI is documented -

http://api.zeromq.org/4-1:zmq-gssapi

all of the ZMQ_Xxx items are options are additive and documented -

http://api.zeromq.org/4-1:zmq-setsockopt

With the exception of ZMQ_SRCFD and ZMQ_SHARED which are message
properties, documented -

http://api.zeromq.org/4-1:zmq-msg-get

zmq_msg_gets() and zmq_has() are new API functions, also documented -

http://api.zeromq.org/4-1:zmq-msg-gets
http://api.zeromq.org/4-1:zmq-has

On Wed, Jan 7, 2015 at 8:55 AM, Peter Kleiweg pklei...@xs4all.nl wrote:


 From the NEWS file:

 0MQ version 4.1.0 rc1, released on 2014/10/14
 =

 * All issues that were fixed in 4.0.x

 * Improved client reconnection strategy on errors

 * GSSAPI security mechanism

 * SOCKS5 support (ZMQ_SOCKS_PROXY)

 * ZMQ_ROUTER_HANDOVER

 * ZMQ_TOS

 * ZMQ_CONNECT_RID

 * ZMQ_HANDSHAKE_IVL

 * ZMQ_IDENTITY_FD

 * ZMQ_XPUB_NODROP

 * ZMQ_SRCFD and ZMQ_SHARED message options

 * Message metadata -- zmq_msg_gets ()

 * Probe library configuration -- zmq_has ()

 Can someone please give an overview of how these things effect
 the C API? What are new functions? What functions have changed?
 What options were added or changed (or removed)?



 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl/
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] C API changes for ZeroMQ 4.1.0

[Thomas Rodgers]

 ZMQ_IDENTITY_FD is get only?


Yes, given a previously set socket identity (see ZMQ_IDENTITY in
http://api.zeromq.org/4-1:zmq-setsockopt), it will return the FD of the
socket associated with that identity.

On Wed, Jan 7, 2015 at 11:48 AM, Peter Kleiweg pklei...@xs4all.nl wrote:

 Thomas Rodgers schreef op de 7e dag van de louwmaand van het jaar 2015:

  GSSAPI is documented -
 
  http://api.zeromq.org/4-1:zmq-gssapi
 
  all of the ZMQ_Xxx items are options are additive and documented -

 ZMQ_IDENTITY_FD is get only?

 I don't see any documentation for ZMQ_XPUB_NODROP




 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl/
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] C API changes for ZeroMQ 4.1.0

[Thomas Rodgers]

 I don't see any documentation for ZMQ_XPUB_NODROP


Issue submitted -

https://github.com/zeromq/libzmq/issues/1287


On Wed, Jan 7, 2015 at 11:48 AM, Peter Kleiweg pklei...@xs4all.nl wrote:

 Thomas Rodgers schreef op de 7e dag van de louwmaand van het jaar 2015:

  GSSAPI is documented -
 
  http://api.zeromq.org/4-1:zmq-gssapi
 
  all of the ZMQ_Xxx items are options are additive and documented -

 ZMQ_IDENTITY_FD is get only?

 I don't see any documentation for ZMQ_XPUB_NODROP




 --
 Peter Kleiweg
 http://pkleiweg.home.xs4all.nl/
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] C API changes for ZeroMQ 4.1.0

[Thomas Rodgers]

For completeness sake, I also added an issue to record the lack of
documentation for ZMQ_SOCKS_PROXY -

https://github.com/zeromq/libzmq/issues/1288

On Wed, Jan 7, 2015 at 9:50 AM, Pieter Hintjens p...@imatix.com wrote:

 Thomas, thanks for summarizing that. I see that ZMQ_SOCKS_PROXY isn't
 documented yet.

 On Wed, Jan 7, 2015 at 4:04 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:
  GSSAPI is documented -
 
  http://api.zeromq.org/4-1:zmq-gssapi
 
  all of the ZMQ_Xxx items are options are additive and documented -
 
  http://api.zeromq.org/4-1:zmq-setsockopt
 
  With the exception of ZMQ_SRCFD and ZMQ_SHARED which are message
 properties,
  documented -
 
  http://api.zeromq.org/4-1:zmq-msg-get
 
  zmq_msg_gets() and zmq_has() are new API functions, also documented -
 
  http://api.zeromq.org/4-1:zmq-msg-gets
  http://api.zeromq.org/4-1:zmq-has
 
  On Wed, Jan 7, 2015 at 8:55 AM, Peter Kleiweg pklei...@xs4all.nl
 wrote:
 
 
  From the NEWS file:
 
  0MQ version 4.1.0 rc1, released on 2014/10/14
  =
 
  * All issues that were fixed in 4.0.x
 
  * Improved client reconnection strategy on errors
 
  * GSSAPI security mechanism
 
  * SOCKS5 support (ZMQ_SOCKS_PROXY)
 
  * ZMQ_ROUTER_HANDOVER
 
  * ZMQ_TOS
 
  * ZMQ_CONNECT_RID
 
  * ZMQ_HANDSHAKE_IVL
 
  * ZMQ_IDENTITY_FD
 
  * ZMQ_XPUB_NODROP
 
  * ZMQ_SRCFD and ZMQ_SHARED message options
 
  * Message metadata -- zmq_msg_gets ()
 
  * Probe library configuration -- zmq_has ()
 
  Can someone please give an overview of how these things effect
  the C API? What are new functions? What functions have changed?
  What options were added or changed (or removed)?
 
 
 
  --
  Peter Kleiweg
  http://pkleiweg.home.xs4all.nl/
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] C++ 0mq helper

[Thomas Rodgers]

You need to create a WikiDot account before you can edit the page.

On Wednesday, December 24, 2014, cibercitizen1 cibercitiz...@gmail.com
wrote:

 Hi all,

 this is the github project:

 https://github.com/cibercitizen1/zmqHelper

 but don't know how to add it to the C++ bindings page.
 Could someone do this for me? (I guess I won't have permissions to do so).

 Thanks.


 El 24/12/14 12:09, Pieter Hintjens wrote:
  Hi, the best way to share this with people is to make a github project
  for it, and then add it to the C++ bindings page at
  http://zeromq.org/bindings:cpp
 
  -Pieter
 

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org javascript:;
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] A design question

[Thomas Rodgers]

The biggest problem with 280, mostly idle, threads would be the amount of
stack space the OS is required to reserve (1MB for Windows/2MB for Linux).
On a 64bit host this is unlikely to be much of an issue.

On Mon, Dec 15, 2014 at 6:11 AM, Pieter Hintjens p...@imatix.com wrote:

 280 threads sounds fine unless you have data showing that it's a
 problem. That's easy to test on your target platform.

 On Sun, Dec 14, 2014 at 7:54 AM, Bob Clarke optiongu...@gmail.com wrote:
  Platform: 0MQ 4.0.4 on Windows 7/Windows Server 2008
 
  I am writing a server monitoring program to replace an ancient (1999)
  program that is almost impossible to maintain.
 
  All of our application servers host proprietary Windows services written
 in
  C++ (except for a couple .Net apps) that use a proprietary synchronous
  request/response system (it works very well, has been for many years, and
  isn't being replaced any time soon).
 
  The monitoring program sends test scripts to the server apps and waits
 for a
  reply. In most cases, the reply is almost immediate, but in some cases,
  there could be a delay of up to 30 seconds. So, to avoid one script
 causing
  delays with others, each test script runs in its own thread. This thread
  must send its results back to a listener, so it creates and uses a 0MQ
  socket to do so. Each test script has a repeat interval; some are run
 every
  five seconds, but most are run every 45 seconds, 90 seconds, or less
  frequently.
 
  There are about 280 test scripts (we have thousands of servers across
 three
  data centers), so I seem to have two unfortunate choices:
  1) Keep the script threads around so I'm not creating and destroying a
  socket each time a test runs;
  2) Let the script threads terminate so I am not keeping 280 threads open
 at
  once. Since the script repeat intervals are quite long in computer terms,
  these threads will spend most of their time do nothing.
 
  I lean towards the first option, but opening and closing sockets that
 often
  doesn't sound good. Then again, keeping 280+ threads around doesn't
 sound so
  great, either.
 
  So before I go too far down this development road, does anyone have some
  experience they could share?
 
  Thanks.
 
  Bob
 
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] event based messaging system

[Thomas Rodgers]

You don't need a timer per request. A typical way to do this sort of
scheduling is to keep a queue ordered by event time, by inserting each new
event into the queue by comparing event times. You set your single timer's
expiration for the event closest to now (eg the head of the queue). When
that event timer expires, you publish your notification, pop the head of
the queue and set the timer to the next nearest event time.

On Friday, December 12, 2014, Vishal Ahuja vahu...@gmail.com wrote:

 I am trying to design an event based messaging system which works as
 follows:

 Let us say that there are multiple products in a store, and their prices
 vary every day. Clients can login to the application, and request to know
 (via SMS) the price of a particular product on a particular date (say 1
 month from the date of login).

 The application will not have access to a database. It will have to
 retrieve the information from a web page. So let us say that the user wants
 to know the price of a product on the 1st of Jan, then the application will
 have to access the website on that particular day itself. Also, another
 detail is that the price of the product can be changed any time during the
 day.

 I am not sure how to design this using zeromq, particularly I am not sure
 how to receive a client request and then act on it after a month or so.
 Will I have to start a timer for every request? Please help me with the
 design.

 Sincerely,

 Vishal





___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Aziomq - Boost Asio compatible C++ bindings for ZeroMQ

[Thomas Rodgers]

Sweet, thanks!

I've forked the repo over to https://github.com/zeromq/aziomq and
deprecated the original repo.

On Wed, Nov 19, 2014 at 3:16 AM, Pieter Hintjens p...@imatix.com wrote:

 OK, you're now invited to the ZeroMQ owners team. Welcome :-)

 On Tue, Nov 18, 2014 at 1:19 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:
  Ugh, yeah wo use git internally and I have my work email set on the
 machine
  I pushed from.
 
  My GitHub account is 'rodgert'
 
  Thanks,
  Tom
 
  On Tuesday, November 18, 2014, Pieter Hintjens p...@imatix.com wrote:
 
  And when I mean zero history, I actually mean you're not committing
  with an email address GitHub recognizes and can link to an account.
 
  On Tue, Nov 18, 2014 at 8:55 AM, Pieter Hintjens p...@imatix.com wrote:
   Oh, i forgot the most important part. I need your GitHub account name.
   Usually I can get this from your project, but you've committed the
   code with zero history...
  
   On Tue, Nov 18, 2014 at 1:09 AM, Thomas Rodgers 
 rodg...@twrodgers.com
   wrote:
   Nice stuff!
  
  
   Thanks!
  
Here's the relevant page: http://zeromq.org/docs:organization
  
  
   Ask on zeromq-dev and you'll be welcomed into the organization
 owners'
   team.
  
   Looking back on my first message, it's not terribly explicit,
 apologies
   for
   that.
  
   I would like to contribute aziomq, a C++ binding that integrates
 ZeroMQ
   with
   Boost Asio to the ZeroMQ organization on GitHub.
  
   You rename your project so it moves into the zeromq organization.
  
   aziomq was a placeholder name (munging asio and zmq). I am happy to
   rename
   it to include some indication of C++ in the name (as is noted in
   http://zeromq.org/docs:bindings) if that is needed. Thoughts?
  
   Decide on a license: we recommend MPLv2.
  
   As it is necessarily used alongside Boost Asio, it is licensed
   according to
   the terms of the Boost license.
  
   Decide on a contribution policy. We recommend the C4.1 process as
 used
   by
   most projects here.
  
   Done, other than additionally documenting my distaste for crappy
 commit
   messages and adhering generally to the existing formatting
 conventions,
   it
   follows http://rfc.zeromq.org/spec:22.
  
   Document the license and contribution policy on your README.
  
   Also done.
  
   Announce the results on Twitter, zeromq-dev, and to your family at
   Sunday
   dinner.
   Wait for the pull requests to come in (it can take time, patience…)
  
   WIP
  
   Thanks,
   Tom.
  
   On Mon, Nov 17, 2014 at 4:59 PM, Pieter Hintjens p...@imatix.com
 wrote:
  
   Hi Thomas,
  
   Nice stuff! Here's the relevant page:
   http://zeromq.org/docs:organization
  
   -Pieter
  
   On Mon, Nov 17, 2014 at 6:06 PM, Thomas Rodgers
   rodg...@twrodgers.com
   wrote:
Yet another C++ binding.
   
This version follows the design and conventions of Boost's Asio
 (see
http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio.html)
library
and
integrates ZeroMQ sockets into Asio's reactor machinery. It is
licensed
under the same terms as Boost Asio (BOOST1.0 license).
   
I had published a previous version of this library a few months
 ago
(see
https://github.com/aziomq/aziomq4-x), but this version has some
design
issues I that I am not entirely comfortable with.
   
I have substantially rewritten the library, which is currently
located
at
https://github.com/aziomq/aziomq. There are still some rough
 edges
and
most
of the sample code still needs to be ported over, but I am
interested in
making it part of the ZeroMQ organization on GitHub and continuing
development from there.
   
Thanks,
Tom.
   
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
   
   ___
   zeromq-dev mailing list
   zeromq-dev@lists.zeromq.org
   http://lists.zeromq.org/mailman/listinfo/zeromq-dev
  
  
  
   ___
   zeromq-dev mailing list
   zeromq-dev@lists.zeromq.org
   http://lists.zeromq.org/mailman/listinfo/zeromq-dev
  
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Aziomq - Boost Asio compatible C++ bindings for ZeroMQ

[Thomas Rodgers]

Ugh, yeah wo use git internally and I have my work email set on the machine
I pushed from.

My GitHub account is 'rodgert'

Thanks,
Tom

On Tuesday, November 18, 2014, Pieter Hintjens p...@imatix.com wrote:

 And when I mean zero history, I actually mean you're not committing
 with an email address GitHub recognizes and can link to an account.

 On Tue, Nov 18, 2014 at 8:55 AM, Pieter Hintjens p...@imatix.com
 javascript:; wrote:
  Oh, i forgot the most important part. I need your GitHub account name.
  Usually I can get this from your project, but you've committed the
  code with zero history...
 
  On Tue, Nov 18, 2014 at 1:09 AM, Thomas Rodgers rodg...@twrodgers.com
 javascript:; wrote:
  Nice stuff!
 
 
  Thanks!
 
   Here's the relevant page: http://zeromq.org/docs:organization
 
 
  Ask on zeromq-dev and you'll be welcomed into the organization owners'
 team.
 
  Looking back on my first message, it's not terribly explicit, apologies
 for
  that.
 
  I would like to contribute aziomq, a C++ binding that integrates ZeroMQ
 with
  Boost Asio to the ZeroMQ organization on GitHub.
 
  You rename your project so it moves into the zeromq organization.
 
  aziomq was a placeholder name (munging asio and zmq). I am happy to
 rename
  it to include some indication of C++ in the name (as is noted in
  http://zeromq.org/docs:bindings) if that is needed. Thoughts?
 
  Decide on a license: we recommend MPLv2.
 
  As it is necessarily used alongside Boost Asio, it is licensed
 according to
  the terms of the Boost license.
 
  Decide on a contribution policy. We recommend the C4.1 process as used
 by
  most projects here.
 
  Done, other than additionally documenting my distaste for crappy commit
  messages and adhering generally to the existing formatting conventions,
 it
  follows http://rfc.zeromq.org/spec:22.
 
  Document the license and contribution policy on your README.
 
  Also done.
 
  Announce the results on Twitter, zeromq-dev, and to your family at
 Sunday
  dinner.
  Wait for the pull requests to come in (it can take time, patience…)
 
  WIP
 
  Thanks,
  Tom.
 
  On Mon, Nov 17, 2014 at 4:59 PM, Pieter Hintjens p...@imatix.com
 javascript:; wrote:
 
  Hi Thomas,
 
  Nice stuff! Here's the relevant page:
 http://zeromq.org/docs:organization
 
  -Pieter
 
  On Mon, Nov 17, 2014 at 6:06 PM, Thomas Rodgers rodg...@twrodgers.com
 javascript:;
  wrote:
   Yet another C++ binding.
  
   This version follows the design and conventions of Boost's Asio (see
   http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio.html)
 library
   and
   integrates ZeroMQ sockets into Asio's reactor machinery. It is
 licensed
   under the same terms as Boost Asio (BOOST1.0 license).
  
   I had published a previous version of this library a few months ago
 (see
   https://github.com/aziomq/aziomq4-x), but this version has some
 design
   issues I that I am not entirely comfortable with.
  
   I have substantially rewritten the library, which is currently
 located
   at
   https://github.com/aziomq/aziomq. There are still some rough edges
 and
   most
   of the sample code still needs to be ported over, but I am
 interested in
   making it part of the ZeroMQ organization on GitHub and continuing
   development from there.
  
   Thanks,
   Tom.
  
   ___
   zeromq-dev mailing list
   zeromq-dev@lists.zeromq.org javascript:;
   http://lists.zeromq.org/mailman/listinfo/zeromq-dev
  
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org javascript:;
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org javascript:;
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org javascript:;
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Aziomq - Boost Asio compatible C++ bindings for ZeroMQ

[Thomas Rodgers]

Yet another C++ binding.

This version follows the design and conventions of Boost's Asio (see
http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio.html) library and
integrates ZeroMQ sockets into Asio's reactor machinery. It is licensed
under the same terms as Boost Asio (BOOST1.0 license).

I had published a previous version of this library a few months ago (see
https://github.com/aziomq/aziomq4-x), but this version has some design
issues I that I am not entirely comfortable with.

I have substantially rewritten the library, which is currently located at
https://github.com/aziomq/aziomq. There are still some rough edges and most
of the sample code still needs to be ported over, but I am interested in
making it part of the ZeroMQ organization on GitHub and continuing
development from there.

Thanks,
Tom.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Aziomq - Boost Asio compatible C++ bindings for ZeroMQ

[Thomas Rodgers]

 Nice stuff!


Thanks!

 Here's the relevant page: http://zeromq.org/docs:organization



   - Ask on zeromq-dev and you'll be welcomed into the organization owners'
   team.

Looking back on my first message, it's not terribly explicit, apologies for
that.

I would like to contribute aziomq https://github.com/aziomq/aziomq, a C++
binding that integrates ZeroMQ with Boost Asio
http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio.html to the
ZeroMQ organization on GitHub.

   - You rename your project so it moves into the zeromq organization.

aziomq was a placeholder name (munging asio and zmq). I am happy to rename
it to include some indication of C++ in the name (as is noted in
http://zeromq.org/docs:bindings) if that is needed. Thoughts?

   - Decide on a license: we recommend MPLv2
   http://en.wikipedia.org/wiki/Mozilla_Public_License.

As it is necessarily used alongside Boost Asio, it is licensed according to
the terms of the Boost license
https://github.com/aziomq/aziomq/blob/master/LICENSE-BOOST_1_0.

   - Decide on a contribution policy. We recommend the C4.1 process
   http://rfc.zeromq.org/spec:22 as used by most projects here.

Done https://github.com/aziomq/aziomq/blob/master/CONTRIBUTING.md, other
than additionally documenting my distaste for crappy commit messages and
adhering generally to the existing formatting conventions, it follows
http://rfc.zeromq.org/spec:22.

   - Document the license and contribution policy on your README.

Also done https://github.com/aziomq/aziomq/blob/master/README.md.


   - Announce the results on Twitter, zeromq-dev, and to your family at
   Sunday dinner.
   - Wait for the pull requests to come in (it can take time, patience…)

WIP

Thanks,
Tom.

On Mon, Nov 17, 2014 at 4:59 PM, Pieter Hintjens p...@imatix.com wrote:

 Hi Thomas,

 Nice stuff! Here's the relevant page: http://zeromq.org/docs:organization

 -Pieter

 On Mon, Nov 17, 2014 at 6:06 PM, Thomas Rodgers rodg...@twrodgers.com
 wrote:
  Yet another C++ binding.
 
  This version follows the design and conventions of Boost's Asio (see
  http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio.html) library
 and
  integrates ZeroMQ sockets into Asio's reactor machinery. It is licensed
  under the same terms as Boost Asio (BOOST1.0 license).
 
  I had published a previous version of this library a few months ago (see
  https://github.com/aziomq/aziomq4-x), but this version has some design
  issues I that I am not entirely comfortable with.
 
  I have substantially rewritten the library, which is currently located at
  https://github.com/aziomq/aziomq. There are still some rough edges and
 most
  of the sample code still needs to be ported over, but I am interested in
  making it part of the ZeroMQ organization on GitHub and continuing
  development from there.
 
  Thanks,
  Tom.
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] Something still slightly wonky with online docs generation

[Thomas Rodgers]

in zmq_term docs (for both 4.1 and 4.0 for instance), the itemized list of
conditions to be satisfied shows up as -


   - After interrupting all blocking calls, *zmq_term()* shall *block* until
   the following conditions are satisfied: itemizedlist listitem All
   sockets open within *context*have been closed with *zmq_close()*.
   - For each socket within *context*, all messages sent by the application
   with*zmq_send()* have either been physically transferred to a network
   peer, or the socket's linger period set with the *ZMQ_LINGER* socket
   option has expired.

The itemizedlist should nest after 'satisfied:' (and probably not leak
the HTML tokens :- )
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] CZMQ community red cards

[Thomas Rodgers]

In reading all of this, I'm of a mixed mind.

Clearly there needs to be some means by which a person who's consistently a
pain in the ass for all of the wrong reasons (history of poor quality
commits, consistently more trouble of than their worth, etc.), and telling
such an individual to go away is likely never going to be completely clear
cut or easy.

Some in this thread have pointed to Linus, his stance on commit quality,
etc. Personally, I agree with being hard-assed about *individual commits*
having a precise summary of what they do, and that such commits be small,
focused, etc. Ideally, pull requests should follow suit, that said, GitHub
allows pull requests to lump together multiple commits, and it's incumbent
on whoever is merging such a request to review *all* of the commits in the
request. Maybe you could quibble over whether the submitter should have
changed the default title assigned from the most recent commit, but it
doesn't excuse you from the responsibility of fully reviewing all commits.
From my reading of this whole affair, it seems that mrvn specifically did
not do this, and then complained about it, as opposed, to saying yep, my
bad, maybe he shouldn't have commit privs, then.

OTOH, Linus has a well established history of being a jackass with respect
to comments on contributors work products.  He has also recently reflected
http://readwrite.com/2014/10/16/linux-linus-torvalds-community-mistakes-toxic-environment
on the mistakes in community building he's made, chief among them being
overly antagonistic towards contributors. Comments along the lines of 'I
don't even want to read the code, it looks like vomit', while tame by
Linus' standards, are still, IMO, fairly toxic however the rest of Pieter's
comment is completely sufficient to convey what was necessary...clean it up
and try again.

Taken on balance, I personally don't see enough in what was offered as
reasoning for the 'red card' to rise to the level of outright banning mrvn,
but I do see at least a couple of lessons on what not to do going forward.

On Fri, Oct 17, 2014 at 11:05 AM, Bjorn Reese bre...@mail1.stofanet.dk
wrote:

 On 10/17/2014 01:16 AM, Pieter Hintjens wrote:

  **You are as of now banned from this list, from CZMQ and all other
  projects I'm a founder of.**

 I suggest that you defer such a decision for a couple of days. Reading
 the links you posted as an objective outsider, I am utterly surprised
 by your reaction. The links look like normal development discussions.
 You have the privilege to reject contributions. There is no need to do
 a public ad hominem.

 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ releases (3.2.5, 4.0.5, 4.1.0)

[Thomas Rodgers]

Any update on a fix?

On Tue, Oct 14, 2014 at 9:33 AM, Pieter Hintjens p...@imatix.com wrote:

 There are still some formatting issues. These pages are built by
 scripts in the ztools project; there's something out of date and
 producing bad results. I'll fix this later today.

 Cheers
 Pieter

 On Tue, Oct 14, 2014 at 4:05 PM, Pieter Hintjens p...@imatix.com wrote:
  Ah, my fault, the laptop I'm using has some missing packages and the
  man pages did not generate accurately. Am rebuilding now on another
  box, thanks for the heads-up.
 
  On Tue, Oct 14, 2014 at 3:34 PM, Arnaud Kapp kapp.a...@gmail.com
 wrote:
  Hello,
 
  The API documentation pages for 4-0, 4-1 and 4-2 are broken. HTML
 formatting
  is off for some reason.
  Maybe this is related this release, I don't really know how the website
  updates work.
 
  On Tue, Oct 14, 2014 at 3:15 PM, Holger Joukl holger.jo...@lbbw.de
 wrote:
 
  zeromq-dev-boun...@lists.zeromq.org schrieb am 14.10.2014 11:08:26:
 
   Von: Pieter Hintjens
   [...]
   - 4.1.0 rc1, with many changes
  
   All on http://zeromq.org/intro:get-the-software as usual.
  
   Also:
  
   * The stabilization fork for 4.1.x is at
  https://github.com/zeromq/zeromq4-1
   ...
 
  https://github.com/zeromq/zeromq4-1/blob/master/NEWS says:
  
  ...
 
   0MQ version 4.1.0 rc1, released on 2014/10/14
 
   =
 
 
 
   * Many changes, see ChangeLog.
 
 
  ...
  
  Is there some dedicated ChangeLog or does this mean the commit
  history of https://github.com/zeromq/zeromq4-1?
 
  Best,
  Holger
 
  Landesbank Baden-Wuerttemberg
  Anstalt des oeffentlichen Rechts
  Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
  HRA 12704
  Amtsgericht Stuttgart
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 
 
 
  --
  Kapp Arnaud - Xaqq
 
  ___
  zeromq-dev mailing list
  zeromq-dev@lists.zeromq.org
  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] DEALER-ROUTER question

[Thomas Rodgers]

Sigh, no good deed goes unpunished...

To your original question -

As covered in the zguide, ZeroMQ is already managing a background thread on
your behalf that is 'pumping' the underlying transport's socket and pulling
messages/sending messages as fast as it can (using epoll, select, IOCP,
etc. as appropriate for the platform).

It is your application's responsibility to determine how best to integrate
that with the application's run-loop on the sending/receiving end of the
ZeroMQ socket. Typically this would done with zmq_poll
http://api.zeromq.org/4-0:zmq-poll and there's a zguide sample to get you
started here http://zguide.zeromq.org/cpp:mspoller. Polling with a
timeout of 0 in a while(1) loop will essentially 'burn' the calling thread
for the purposes of notifying the caller of which sockets have at least one
message ready to be received (ZMQ_POLLIN) and/or at least one message can
be sent (ZMQ_POLLOUT).

How to best integrate this into your application, is highly dependent on
your application, it's latency requirements, etc.

To the rest -

Pieter has certainly done more work on libzmq/czmq, it's documentation and
ZeroMQ advocacy than any other individual.  Pieter continues to do
substantial ongoing development work on ZeroMQ, hardly consistent with
usual connotations attached to the term figurehead.

I have to admit I'm a bit baffled at the assertion about hwserver code in
the zguide not demonstrating how to pull out the contents of the payload.
It is precisely the same as putting the payload *INTO* the message, with
msg.data() being the source rather than the destination argument to memcpy,
and you needing to provide an appropriate destination (char array,
std::arraychar, std::vectorchar) and calling msg.size() to get the
actual message size.

The zguide is not intended to be a guide on basic usage of standard C/C++,
their common idioms and standard libraries.

MSDN has complete documentation on the use of memcpy at -

http://msdn.microsoft.com/en-us/library/dswaw1wk.aspx

Nor is the zguide intended to be a more verbose replacement for the ZeroMQ
reference manual -

http://api.zeromq.org/

You actually do need to use both documents.

If you are basing your code on zmq.hpp, the zguide is in no way intended to
replace reading the source -

https://github.com/zeromq/cppzmq/blob/master/zmq.hpp

It is a very thin wrapper over the libzmq API, which is the only core
documentation requirement.

If you want to serialize objects and send them over ZMQ, you should be
looking at an existing framework (MFC has one, so does Boost
http://www.boost.org/doc/libs/1_56_0/libs/serialization/doc/index.html).
Both support serialization to an arbitrary byte buffer, of which
zmq::message_t is, but it is well beyond the scope of the zguide to tell
you how, for instance, you might implement the Boost Serialization archive
concept (or *anything* to do with MFC) on top of zmq::message_t.

I spent a significant chunk of the last 25 years as a C++ developer on
Microsoft's platforms and using Microsoft's development tools. In my
experience it has been exceedingly rare to find open source projects which
begin life on *nix that magically 'just work' on the Windows platform. When
I needed a particular bit of open source to work on Windows, I did the work
fix the issues, recognizing that Windows was a decided non-priority for the
developers of the project in question. That ZeroMQ attempts to provide
actual builds and ports for Windows is a Good Thing, but it requires the
people who actually use that platform regularly (no longer one of those
people, sorry) to contribute to keeping those build targets current.



On Thu, Sep 25, 2014 at 8:08 AM, Riskybiz riskybizl...@live.com wrote:

 Dear Pieter,

 As a figurehead of the zeromq project I think you should know that the
 zguide and its examples, whilst a worthy effort, is actually a barrier to
 the progress of a learner.  As a newcomer to networking my interactions and
 attempts to learn and use zeromq over the past year has been an unyielding
 source of issues to be overcome.  Anyone else would probably have given up,
 but I recognise the benefits of the superb technology offered by zeromq.

 Part of the problem is perhaps that the zguide has been written by experts,
 where seemingly minor details are glossed over.  For example in the
 hwserver
 and hwclient code it is not demonstrated how actually to read a message
 payload from the socket and extract the received message string.  It cheats
 and prints; printf (Received World %d\n, request_nbr);  When someone
 tries
 this early example the first thing they will experiment with is:  How can I
 customise the message payload and get my own message sent and received?
 They will be disappointed.  They might read on try to figure it out and be
 baffled by the multiple language bindings, apis and helper files and left
 wondering; what actually needs to be written to make zeromq work?  What is
 the core underlying zeromq commands which 

Re: [zeromq-dev] ZMQ appends weird characters to message

[Thomas Rodgers]

When you create a message via zmq_init_data() (which zmq::message_t does
with the constructor args you specified, and specify NULL for the ffn
argument, it becomes a const message, which means that ZeroMQ assumes
ownership of the pointer you handed it (it's a cmsg type, e.g. *const*
data).  It does not make a copy (see msg.cpp line 86 in the zmq 4.0
sources).  If you then use std::string to modify the string contents
*before* the receiving side has constructed it's copy the string, you are
going to see corrupted data.


On Mon, Sep 15, 2014 at 10:02 AM, Dávid Kaya m...@davidkaya.sk wrote:

 Well I tried to recreate the problem but it works as intended in my
 short example. I really don't know where could be the problem since I am
 doing it exactly the same way in my example as in my application. Maybe
 the problem is in the std::string, because when I use
 std::string.replace() to replace some characters in the URL then it
 works fine. But when I dont use it and append the URL to success:
 message right away, then it does not work. So maybe
 std::string.replace() somehow fixes the string when it rearranges it.
 The first problem with login was because I wasn't using size() in
 string constructor.

 David

 On 15.09.2014 17:56, gonzalo diethelm wrote:
  Please create a short (as short as possible) example that shows this
  symptom, and post it to the list.
 
  --
  Gonzalo Diethelm
  DCV Chile
 
  -Original Message-
  From: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-
  boun...@lists.zeromq.org] On Behalf Of Dávid Kaya
  Sent: Monday, September 15, 2014 12:39 PM
  To: ZeroMQ development list
  Subject: Re: [zeromq-dev] ZMQ appends weird characters to message
 
  Yes, I've printed that message. There can't be any NULL byte there.
  It is string
  success: appended with url. It is normal url like
  http://example.org/path/to/jsp?lang=en_US?session=session id
  here.
  That session ID contains numbers, characters and dashes.
 
 
  On 15.09.2014 17:30, gonzalo diethelm wrote:
   No, this is not a (known) limitation. Did you print exactly what
  you
   are sending and what you are receiving? My guess is you are
  putting a
   null byte in the middle of what you are sending.
  
   --
   Gonzalo Diethelm
   DCV Chile
  
   -Original Message-
   From: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-
   boun...@lists.zeromq.org] On Behalf Of Dávid Kaya
   Sent: Monday, September 15, 2014 12:21 PM
   To: zeromq-dev@lists.zeromq.org
   Subject: Re: [zeromq-dev] ZMQ appends weird characters to message
  
   Well, I've printed out size and it is correct. I've also
  shortened
   the message by 5 characters and it stopped cutting off the last
   characters (atleast I think it stopped, tried 15 times and it
  came
   correct every time). So I think the problem was in the length of
  the
   message. I don't know if it is a bug in ZMQ or system limitation
  of
   socket files?
  
   David
  
  
   On 15.09.2014 16:47, gonzalo diethelm wrote:
Good point. Forgot about the specific details for that C++
constructor. The null byte should not be required.
   
As Tom points out, you should print out what you are sending
  and
receiving (contents and length) and make sure it makes sense.
   
HTH.
   
--
Gonzalo Diethelm
DCV Chile
   
-Original Message-
From: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-
boun...@lists.zeromq.org] On Behalf Of Tom Quarendon
Sent: Monday, September 15, 2014 11:42 AM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] ZMQ appends weird characters to
  message
   
 You have two choices:
 1. Send the '\0' as part of the message (and set length to
  one
more byte).
 2. Append a '\0' after receiving the message.
   
Uh, why?
string(static_castchar*(reply.data()),reply.size());
doesn't assume the string is null terminated. It constructs
   string
from pointer and length. Isn't adding a in a null just going
  mask
   the
real issue and make it look like the std::string only
  contained
login when really it still contained the extra stuff as
  well.
David, Do you know what reply.size() actually contains? Have
  you
tried printing that out and comparing it to what you expect?
   
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
   
   
-
Declaración de confidencialidad: Este Mensaje esta destinado
  para
   el
uso de la o las personas o entidades a quien ha sido dirigido y
   puede
contener información reservada y confidencial que no puede ser
divulgada, difundida, ni aprovechada en forma alguna. El uso no
autorizado de la información contenida en este correo podrá ser
sancionado de conformidad con la ley chilena.
Si usted ha recibido este correo electrónico por 

Re: [zeromq-dev] ZMQ appends weird characters to message

[Thomas Rodgers]

Message goes out of scope, destructor called, receiving side is getting a
pointer to a free'd heap block.


On Mon, Sep 15, 2014 at 10:27 AM, Dávid Kaya m...@davidkaya.sk wrote:

 Here is that function: http://pastebin.com/AgUuDqqK .


 On 15.09.2014 19:19, gonzalo diethelm wrote:
  Without seeing any actual code, it is impossible to say.
 
  --
  Gonzalo Diethelm
  DCV Chile
 
  -Original Message-
  From: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-
  boun...@lists.zeromq.org] On Behalf Of Dávid Kaya
  Sent: Monday, September 15, 2014 2:18 PM
  To: ZeroMQ development list
  Subject: Re: [zeromq-dev] ZMQ appends weird characters to message
 
  If it would be because of memory, the std::string.replace() would
  not fix,
  would it? Everything is done in one function, I don't think this is
  the problem.
 
 
  On 15.09.2014 19:11, gonzalo diethelm wrote:
   That usually happens... Try to focus on the differences between
  your
   short example and your real code.
  
   One point to focus on could be memory management: are you sure the
   messages you are sending are actually surviving until they get
  sent?
   A
   simple wrong way to manage this would be putting your messages in
  an
   automatic variable that gets overwritten when you leave the
  function
   that sends the message. Another wrong way would be using a static
   buffer for your messages, that gets overwritten with each message.
  
   HTH.
  
   --
   Gonzalo Diethelm
   DCV Chile
  
   -Original Message-
   From: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-
   boun...@lists.zeromq.org] On Behalf Of Dávid Kaya
   Sent: Monday, September 15, 2014 2:02 PM
   To: ZeroMQ development list
   Subject: Re: [zeromq-dev] ZMQ appends weird characters to message
  
   Well I tried to recreate the problem but it works as intended in
  my
   short example. I really don't know where could be the problem
  since I
   am doing it exactly the same way in my example as in my
  application.
   Maybe the problem is in the std::string, because when I use
   std::string.replace() to replace some characters in the URL then
  it
   works fine.
   But when I dont use it and append the URL to success:
   message right away, then it does not work. So maybe
   std::string.replace() somehow fixes the string when it rearranges
  it.
   The first problem with login was because I wasn't using size()
  in
   string constructor.
  
   David
  
   On 15.09.2014 17:56, gonzalo diethelm wrote:
Please create a short (as short as possible) example that shows
   this
symptom, and post it to the list.
   
--
Gonzalo Diethelm
DCV Chile
   
-Original Message-
From: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-
boun...@lists.zeromq.org] On Behalf Of Dávid Kaya
Sent: Monday, September 15, 2014 12:39 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] ZMQ appends weird characters to
  message
   
Yes, I've printed that message. There can't be any NULL byte
   there.
It is string
success: appended with url. It is normal url like
http://example.org/path/to/jsp?lang=en_US?session=session id
   here.
That session ID contains numbers, characters and dashes.
   
   
On 15.09.2014 17:30, gonzalo diethelm wrote:
 No, this is not a (known) limitation. Did you print exactly
   what
you
 are sending and what you are receiving? My guess is you are
putting a
 null byte in the middle of what you are sending.

 --
 Gonzalo Diethelm
 DCV Chile

 -Original Message-
 From: zeromq-dev-boun...@lists.zeromq.org
  [mailto:zeromq-dev-
 boun...@lists.zeromq.org] On Behalf Of Dávid Kaya
 Sent: Monday, September 15, 2014 12:21 PM
 To: zeromq-dev@lists.zeromq.org
 Subject: Re: [zeromq-dev] ZMQ appends weird characters to
   message

 Well, I've printed out size and it is correct. I've also
shortened
 the message by 5 characters and it stopped cutting off the
   last
 characters (atleast I think it stopped, tried 15 times and
  it
came
 correct every time). So I think the problem was in the
  length
   of
the
 message. I don't know if it is a bug in ZMQ or system
   limitation
of
 socket files?

 David


 On 15.09.2014 16:47, gonzalo diethelm wrote:
  Good point. Forgot about the specific details for that
  C++
  constructor. The null byte should not be required.
 
  As Tom points out, you should print out what you are
  sending
and
  receiving (contents and length) and make sure it makes
   sense.
 
  HTH.
 
  --
  Gonzalo Diethelm
  DCV Chile
 
  -Original Message-
  From: zeromq-dev-boun...@lists.zeromq.org
   [mailto:zeromq-dev-
  boun...@lists.zeromq.org] On Behalf Of Tom Quarendon
  Sent: Monday, September 15, 2014 11:42 AM
  To: ZeroMQ development list
  Subject: 

Re: [zeromq-dev] ZMQ appends weird characters to message

[Thomas Rodgers]

You can do something like -

zmq::message_t ackMessage(message.size());
std::copy_n(message.data(), message.size(), ackMessage.data());

This constructor form will cause the message to allocate it's own storage
(and thus free it appropriately), you then copy the contents of your string
into the storage managed by the message.


On Mon, Sep 15, 2014 at 10:44 AM, Dávid Kaya m...@davidkaya.sk wrote:

 Oh thanks a lot, didn't know this. So the correct way would be to have
 one pointer to message_t as a member of my class and before every send()
 I should rebuild it and delete it manually when I am done with the
 socket, right? Or should I have (message_t*) for every message I use?

 On 15.09.2014 19:30, Thomas Rodgers wrote:
  Message goes out of scope, destructor called, receiving side is
  getting a pointer to a free'd heap block.
 
  On Mon, Sep 15, 2014 at 10:27 AM, Dávid Kaya  wrote:
 
  Here is that function: http://pastebin.com/AgUuDqqK [1] .
 
  On 15.09.2014 19:19, gonzalo diethelm wrote:
   Without seeing any actual code, it is impossible to say.
  
   --
   Gonzalo Diethelm
   DCV Chile
  
   -Original Message-
   From: zeromq-dev-boun...@lists.zeromq.org [2]
  [mailto:zeromq-dev- [3]
   boun...@lists.zeromq.org [4]] On Behalf Of Dávid Kaya
   Sent: Monday, September 15, 2014 2:18 PM
   To: ZeroMQ development list
   Subject: Re: [zeromq-dev] ZMQ appends weird characters to
  message
  
   If it would be because of memory, the std::string.replace()
  would
   not fix,
   would it? Everything is done in one function, I don't think this
  is
   the problem.
  
  
   On 15.09.2014 19:11, gonzalo diethelm wrote:
That usually happens... Try to focus on the differences
  between
   your
short example and your real code.
   
One point to focus on could be memory management: are you sure
  the
messages you are sending are actually surviving until they get
   sent?
A
simple wrong way to manage this would be putting your messages
  in
   an
automatic variable that gets overwritten when you leave the
   function
that sends the message. Another wrong way would be using a
  static
buffer for your messages, that gets overwritten with each
  message.
   
HTH.
   
--
Gonzalo Diethelm
DCV Chile
   
-Original Message-
From: zeromq-dev-boun...@lists.zeromq.org [5]
  [mailto:zeromq-dev- [6]
boun...@lists.zeromq.org [7]] On Behalf Of Dávid Kaya
Sent: Monday, September 15, 2014 2:02 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] ZMQ appends weird characters to
  message
   
Well I tried to recreate the problem but it works as intended
  in
   my
short example. I really don't know where could be the problem
   since I
am doing it exactly the same way in my example as in my
   application.
Maybe the problem is in the std::string, because when I use
std::string.replace() to replace some characters in the URL
  then
   it
works fine.
But when I dont use it and append the URL to success:
message right away, then it does not work. So maybe
std::string.replace() somehow fixes the string when it
  rearranges
   it.
The first problem with login was because I wasn't using
  size()
   in
string constructor.
   
David
   
On 15.09.2014 17:56, gonzalo diethelm wrote:
 Please create a short (as short as possible) example that
  shows
this
 symptom, and post it to the list.

 --
 Gonzalo Diethelm
 DCV Chile

 -Original Message-
 From: zeromq-dev-boun...@lists.zeromq.org [8]
  [mailto:zeromq-dev- [9]
 boun...@lists.zeromq.org [10]] On Behalf Of Dávid Kaya
 Sent: Monday, September 15, 2014 12:39 PM
 To: ZeroMQ development list
 Subject: Re: [zeromq-dev] ZMQ appends weird characters to
   message

 Yes, I've printed that message. There can't be any NULL
  byte
there.
 It is string
 success: appended with url. It is normal url like
 http://example.org/path/to/jsp?lang=en_US?session=
  [11]session id
here.
 That session ID contains numbers, characters and dashes.


 On 15.09.2014 17:30, gonzalo diethelm wrote:
  No, this is not a (known) limitation. Did you print
  exactly
what
 you
  are sending and what you are receiving? My guess is you
  are
 putting a
  null byte in the middle of what you are sending.
 
  --
  Gonzalo Diethelm
  DCV Chile
 
  -Original Message-
  From: zeromq-dev-boun...@lists.zeromq.org [12]
   [mailto:zeromq-dev- [13]
  boun...@lists.zeromq.org [14]] On Behalf Of Dávid Kaya
  Sent: Monday, September 15, 2014 12:21 PM
  To: zeromq-dev@lists.zeromq.org [15]
  Subject: Re: [zeromq-dev] ZMQ appends weird characters
  to
message
 
  Well, I've printed out size and it is correct. I've
  also
 shortened
  the message by 5 characters and it stopped cutting off

Re: [zeromq-dev] ZMQ appends weird characters to message

[Thomas Rodgers]

You will need cast ackMessage.data() to char* (e.g.
static_castchar*(ackMessage.data())) for that to work.


On Mon, Sep 15, 2014 at 10:52 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:

 You can do something like -

 zmq::message_t ackMessage(message.size());
 std::copy_n(message.data(), message.size(), ackMessage.data());

 This constructor form will cause the message to allocate it's own storage
 (and thus free it appropriately), you then copy the contents of your string
 into the storage managed by the message.


 On Mon, Sep 15, 2014 at 10:44 AM, Dávid Kaya m...@davidkaya.sk wrote:

 Oh thanks a lot, didn't know this. So the correct way would be to have
 one pointer to message_t as a member of my class and before every send()
 I should rebuild it and delete it manually when I am done with the
 socket, right? Or should I have (message_t*) for every message I use?

 On 15.09.2014 19:30, Thomas Rodgers wrote:
  Message goes out of scope, destructor called, receiving side is
  getting a pointer to a free'd heap block.
 
  On Mon, Sep 15, 2014 at 10:27 AM, Dávid Kaya  wrote:
 
  Here is that function: http://pastebin.com/AgUuDqqK [1] .
 
  On 15.09.2014 19:19, gonzalo diethelm wrote:
   Without seeing any actual code, it is impossible to say.
  
   --
   Gonzalo Diethelm
   DCV Chile
  
   -Original Message-
   From: zeromq-dev-boun...@lists.zeromq.org [2]
  [mailto:zeromq-dev- [3]
   boun...@lists.zeromq.org [4]] On Behalf Of Dávid Kaya
   Sent: Monday, September 15, 2014 2:18 PM
   To: ZeroMQ development list
   Subject: Re: [zeromq-dev] ZMQ appends weird characters to
  message
  
   If it would be because of memory, the std::string.replace()
  would
   not fix,
   would it? Everything is done in one function, I don't think this
  is
   the problem.
  
  
   On 15.09.2014 19:11, gonzalo diethelm wrote:
That usually happens... Try to focus on the differences
  between
   your
short example and your real code.
   
One point to focus on could be memory management: are you sure
  the
messages you are sending are actually surviving until they get
   sent?
A
simple wrong way to manage this would be putting your messages
  in
   an
automatic variable that gets overwritten when you leave the
   function
that sends the message. Another wrong way would be using a
  static
buffer for your messages, that gets overwritten with each
  message.
   
HTH.
   
--
Gonzalo Diethelm
DCV Chile
   
-Original Message-
From: zeromq-dev-boun...@lists.zeromq.org [5]
  [mailto:zeromq-dev- [6]
boun...@lists.zeromq.org [7]] On Behalf Of Dávid Kaya
Sent: Monday, September 15, 2014 2:02 PM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] ZMQ appends weird characters to
  message
   
Well I tried to recreate the problem but it works as intended
  in
   my
short example. I really don't know where could be the problem
   since I
am doing it exactly the same way in my example as in my
   application.
Maybe the problem is in the std::string, because when I use
std::string.replace() to replace some characters in the URL
  then
   it
works fine.
But when I dont use it and append the URL to success:
message right away, then it does not work. So maybe
std::string.replace() somehow fixes the string when it
  rearranges
   it.
The first problem with login was because I wasn't using
  size()
   in
string constructor.
   
David
   
On 15.09.2014 17:56, gonzalo diethelm wrote:
 Please create a short (as short as possible) example that
  shows
this
 symptom, and post it to the list.

 --
 Gonzalo Diethelm
 DCV Chile

 -Original Message-
 From: zeromq-dev-boun...@lists.zeromq.org [8]
  [mailto:zeromq-dev- [9]
 boun...@lists.zeromq.org [10]] On Behalf Of Dávid Kaya
 Sent: Monday, September 15, 2014 12:39 PM
 To: ZeroMQ development list
 Subject: Re: [zeromq-dev] ZMQ appends weird characters to
   message

 Yes, I've printed that message. There can't be any NULL
  byte
there.
 It is string
 success: appended with url. It is normal url like
 http://example.org/path/to/jsp?lang=en_US?session=
  [11]session id
here.
 That session ID contains numbers, characters and dashes.


 On 15.09.2014 17:30, gonzalo diethelm wrote:
  No, this is not a (known) limitation. Did you print
  exactly
what
 you
  are sending and what you are receiving? My guess is you
  are
 putting a
  null byte in the middle of what you are sending.
 
  --
  Gonzalo Diethelm
  DCV Chile
 
  -Original Message-
  From: zeromq-dev-boun...@lists.zeromq.org [12]
   [mailto:zeromq-dev- [13]
  boun...@lists.zeromq.org [14]] On Behalf Of Dávid Kaya
  Sent: Monday, September 15, 2014 12:21 PM
  To: zeromq-dev@lists.zeromq.org [15]
  Subject: Re: [zeromq-dev] ZMQ

Re: [zeromq-dev] ZMQ appends weird characters to message

[Thomas Rodgers]

How do you display the string on the receiving end?

On Sunday, September 14, 2014, Dávid Kaya m...@davidkaya.sk wrote:

 Hi,

 Let's say I have a message like this one:

 string loginMessage = login;
 zmq::message_t
 request((void*)loginMessage.c_str(),loginMessage.length(),NULL);

 whenever I send it, it comes like this: loginY Socket-Type. There is
 also a empty box after Y. Then when I send a url, (120 characters
 approx.), zmq cuts off last couple of characters and replace them with
 '@' followed by empty boxes. It's always same characters, it does not
 change. It's a 'Y' with empty box in login message and '@' with empty
 boxes in url message.

 I use IPC socket (REP/REQ) on linux (created in /tmp/*socket*), zmq
 version 4.0.4 and c++ binding (last version).

 Thanks,

 David
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org javascript:;
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev