Solution: restore inclusion of poll.h if using poll before zmq.h as
it was originally, as AIX redefines the POSIX structures and provides
compatibility macros.
Also add alternative aliases for 32 bit AIX's pollitem struct:
events -> reqevents
revents -> rtnevents
Solution: try to detect architecture if building with VC++ and
hardcode pointer size accordingly.
Expressions are not allowed inside declspec intrinsics, which
includes other intrinsics.
Solution: use compiler's alignment attributes instead which is
clearer and less of a hack.
Pointer alignment violations causing crashes on architectures
such as sparc64 and aarch64.
This also avoid triggering ABI checkers as the change is compatible
even though applications that suffer from the bug should rebuild to
take advantage of the fix.
Solution: zmq_poller_wait_all signals all events
allows signaling multiple events with one call to zmq_poller_wait_all
rather than emitting only one event.
this prepares for zmq_poll being based on zmq_poller,
which requires events for all sockets rather than just one.
Solution:
As preparation for 4.2 release, move the zmq_sendiov and zmq_recviov API
methods under the Deprecated Methods section.
Note: the actual methods have NOT been deprecated yet, functionally speaking
however it is good to let API users know early. Moreover, these methods were
not ever considered stable, at least according to src/zmq.h, and have no
associated man pages.
Problem: Recent deprecation of the "zmq_utils.h" header file caused pedantic compilations (including czmq) to fail because non-portable #warning is used.
Solution: Limit the deprecation warnings to compilers known or assumed to support the "#pragma message" (GCC, MSVC, CLANG) and wrap with GCC directives to not treat these warnings as errors on paranoid builds.
And I'm on a reasonably sized laptop. I think allocating INT_MAX
memory is dangerous in a test case.
Solution: expose this as a context option. I've used ZMQ_MAX_MSGSZ
and documented it and implemented the API. However I don't know how
to get the parent context for a socket, so the code in zmq.cpp is
still unfinished.
These options are confusing and redundant. Their names suggest
they apply to the tcp:// transport, yet they are used for all
stream protocols. The methods zmq::set_tcp_receive_buffer and
zmq::set_tcp_send_buffer don't use these values at all, they use
ZMQ_SNDBUF and ZMQ_RCVBUF.
Solution: merge these new options into ZMQ_SNDBUF and ZMQ_RCVBUF.
This means defaulting these two options to 8192, and removing the
new options. We now have ZMQ_SNDBUF and ZMQ_RCVBUF being used both
for TCP socket control, and for input/output buffering.
Note: the default for SNDBUF and RCVBUF are otherwise 4096.
This option has a few issues. The name is long and clumsy. The
functonality is not smooth: one must set both this and
ZMQ_XPUB_VERBOSE at the same time, or things will break mysteriously.
Solution: rename to ZMQ_XPUB_VERBOSER and make an atomic option.
That is, implicitly does ZMQ_XPUB_VERBOSE.
Solution: add new [set|get]sockopt ZMQ_PRE_ALLOCATED_FD to allow
users to let ZMQ use a pre-allocated file descriptor instead of
allocating a new one. Update [set|get]sockopt documentation and
test accordingly.
The main use case for this feature is a socket-activated systemd
service. For more information about this feature see:
http://0pointer.de/blog/projects/socket-activation.html
I hope restoring this from a previous version doesn't do any damage, it
is missing in the current version of this repository and is vital for
the lib to compile anywhere.
If we're going to add CLASS-like APIs we should use the proper
syntax; specifically 'destroy' instead of 'close', which is a
hangover from the 'ZeroMQ is like sockets' model we're slowly
moving away from.
Solution: change zmq_timers_close(p) to zmq_timers_destroy(&p)
VMCI transport allows fast communication between the Host
and a virtual machine, between virtual machines on the same host,
and within a virtual machine (like IPC).
It requires VMware to be installed on the host and Guest Additions
to be installed on a guest.
Fixes not receiving unsubscription messages in XPUB socket with
ZMQ_XPUB_VERBOSE and using a XSUB-XPUB proxy in front.
This adds two modifications:
- It adds a new flag, ZMQ_XPUB_VERBOSE_UNSUBSCRIBE, to enable verbose
unsubscription messages, necessary when using a XSUB/XPUB proxy.
- It adds a boolean switch to zmq::mtrie_t::rm () to control if the
callback is invoked every time or only in the last removal. Necessary
when a pipe is terminated and the verbose mode for unsubscriptions is
enabled.
Of course people still "can" distributed the sources under the
LGPLv3. However we provide COPYING.LESSER with additional grants.
Solution: specify these grants in the header of each source file.
ZMQ_INVERT_MATCHING reverses the PUB/SUB prefix matching. The subscription
list becomes a rejection list. The PUB socket sends messages to all
connected (X)SUB sockets that do not have any matching subscription.
Whenever the option is used on a PUB/XPUB socket, any connecting SUB
sockets must also set it or they will reject everything the publisher
sends them. XSUB sockets are unaffected because they do not filter out
incoming messages.
Symptom is that ZMQ_STREAM sockets in 4.1.0 and 4.1.1 generate zero
sized messages on each new connection, unlike 4.0.x which did not do
this.
Person who made this commit also changed test cases so that contract
breakage did not show. Same person was later banned for persistently
poor form in CZMQ contributions.
Solution: enable connect notifications on ZMQ_STREAM sockets using a
new ZMQ_STREAM_NOTIFY setting. By default, socket does not deliver
notifications, and behaves as in 4.0.x.
Fixes#1316
Increasing it would have at least two benefits -
* More messages would be 'VSM' messages, so it would reduce allocation
overhead a bit.
* Remove any chance of false sharing of things that are, by design,
pushed by value onto a ypipe_t<msg_t> which is shared between two threads.
The only downside I see is slightly increased memory consumption on memory
constrained applications.
- Full discussion of this rationale is part of issue #1295
Firstly, only a few types are defined, leaving it hard for higher layers
to complete the set. Secondly, the code incorrectly tries to use ifndef
to avoid re-defining typedefs, which does not work in C.
Solution: define all types, unconditionally for all MSVC compilers.
Additionally, define ZMQ_DEFINED_STDINT that tells higher layers that we
already defined these integer types.
zmq_atomic_counter_dec returned a 'bool' value, yet this isn't
defined by standard, so causes compile errors in upstream code.
Solution: return an int that can be safely converted to bool if
needed by bindings.
Solution: as libzmq already provides this across all platforms,
expose an atomic counter API. I've not wrapped atomic pointers,
though someone who needs this may want to do so.
Solution: set defaults back to infinity, and add new context
option, ZMQ_BLOCKY that the user can set to false to get a
less surprising behavior on context termination. Eg.
zmq_ctx_set (ctx, ZMQ_BLOCKY, false);
This commit adds a ZMQ_POLLPRI flag that maps to poll()'s POLLPRI
flag.
This flags does nothing for OMQ sockets. It's only useful for raw
file descriptor (be it socket or file).
This flag does nothing if poll() is not the underlying polling
function. So it is Linux only.
