Solution: prefer CXX11 atomics if they are available to compiler
intrinsics.
test_hwm_pubsub fails 50% of the times on PPC64 and RISC-V with an
apparent memory corruption of messages sent by the application thread
to the I/O thread when using compiler intrinsics.
Switching to CXX11 atomics makes the test reliable again. The
standard API should be preferred anyway, if available.
Solution: detect cacheline size for aligment purposes at build time
instead of hard-coding it, so that PPC and S390 can align to a value
greater than the 64 bytes default.
Uses libc getconf program, and falls back to the previous value of 64
if not found.
Solution: remove documents and tests for ZMQ_THREAD_PRIORITY getter. It
never worked and can never work as it has the same value as a get-only
option ZMQ_SOCKET_LIMIT. It cannot be changed without breaking ABI.
Note that the setter works fine as ZMQ_SOCKET_LIMIT is get-only.
Solution: if a multi-part message cannot be delivered by a PUSH socket
because the pipe is broken mid-way, drop the rest of the frames so that
the atomicity property is not broken.
Solution: use requires.private, which pkg-config expands recursively
so that dependencies of dependencies can be linked against when
using pkg-config --static
Solution: go back to using -Wl,--version-script.
Use ax_check_vscript.m4 from the autoconf-archive to detect support on
multiple platforms (eg Solaris ld(1) -M).
libtool -export-symbols-regexp used ld(1) --retain-symbols-file under
the hood, the latter lets some C++ weak symbols make their way into the
dynamic symbols table, along with the zmq_* interface. The reason for
such behavior is unknown to me.
Solution: switch to libtool symbol visibility support, which leads to
more portable constructs in the autotools glue. As noted in the libtool
documentation "This option has no effect on some platforms."
After this commit, global symbols intended to be kept private will
disappear on platforms that were previously not handled
using -Wl,--version-script.
Solution: temporary revert refactoring until it can be properly fixed.
Revert "Problem: complexity of start_connecting"
This reverts commit 6d7aeb056f11e6fd2429fa90bc175da0922d306b.
* ZMQ_DGRAM: flip more flag after successful send
In the dgram socket we have a flag that indicates the next expected message type to ensure that always a pair of "address" + "body" messages gets sent. The first one MUST have the sendmore flag, the second MUST NOT.
In case the message does not get sent because of HWM full, then the function returns EAGAIN as it should. But unfortunately the next expected message type-flag gets flipped as well. When the socket_base::send function now tries to resend the message, it became the wrong message type... If you don't stop sending pairs of messages here (like me) then the next message that gets through will be of the wrong type, which in turn crashes the udp_engine function as described in #3268
This patch fixes an issue that occurs on 64-bit architetures under
strict compiler rules. The code initially checked that the received
size stored in 'uint64_t' was not bigger than the max value of a
'size_t' variable, which is legitimate on 32-bit architectures where
'size_t' variables are stored on 32 bits. On 64-bit architectures,
this test no longer makes sense since 'uint64_t' and 'size_t' types
have the same size. The issue is fixed by ignoring this portion
of code when built for arm64.
