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 6d7aeb056f.
* 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.
The variable decrement was changed to decrement_
in c581f43c97
In -one- place, it remained as decrement
and gives:
In file included from src/ctx.hpp:44:0,
from src/address.cpp:33:
src/atomic_counter.hpp: In member function 'bool zmq::atomic_counter_t::sub(zmq::atomic_counter_t::integer_t)':
src/atomic_counter.hpp:191:28: error: 'decrement' was not declared in this scope
Changing it to decrement_ fixes the problem.
Problem: PGM receiver can crash due to race
Solution: do not run in_event until restart_input finishes correctly.
Signed-off-by: answeroo <jiming@yafco.com>
