contributors and doesn't reflect the real process. I've taken out all named
authors and referred to the contribution policy. Hopefully this will improve
the contributions to the man pages.
zmq::xpub_t::xread_activated() – change to process messages without 0
or 1 prefix, but without affecting subscriptions
zmq::xsub_t::xsend() – change to send rather than discard messages
without 0 or 1 prefix, but without affecting subscriptions
Update documentation
The previous note in connect introduced but did not elaborate on the
requirement to bind before connect in inproc. As that discussion is in
detail in the inproc docs link to there.
Based on discussion with Steve O on the list, make the difference
between bind and connect usage more clear, and add a note reflecting the
fact that inproc must have bind before connect to reinforce the
information in zmq_inproc.
This patch, salvaged from a trainwreck accidental merge earlier, adds a
new sockopt, ZMQ_DELAY_ATTACH_ON_CONNECT which prevents a end point
being available to push messages to until it has fully connected, making
connect work more like bind. This also applies to reconnecting sockets,
which may cause message loss of in-queue messages, so it is sensible to
use this in conjunction with a low HWM and potentially an alternative
acknowledgement path.
Notes on most of the individual commits can be found the repository log.
This patch adds a sockopt ZMQ_DELAY_ATTACH_ON_CONNECT, which if set to 1 will attempt to preempt this behavior. It does this by extending the use of the session_base to include in the outbound as well as the inbound pipe, and only associates the pipe with the socket once it receives the connected callback via a process_attach message. This works, and a test has been added to show so, but may introduce unexpected complications. The shutdown logic in this class has become marginally more awkward because of this, requiring the session to serve as the sink for both pipes if shutdown occurs with a still-connecting pipe in place. It is also possible there could be issues around flushing the messages, but as I could not directly think how to create such an issue I have not written any code with regards to that.
The documentation has been updated to reflect the change, but please do check over the code and test and review.
