Trying to optimize out the case where items_[i]. events is 0 would
result in a bogus pollfds[i]. Similarly in the select()-based impl,
while not strictly necessary it's better to get ZMQ_FD even if
events is 0 since that detects ETERM and friends.
Rewrite the select()-based zmq_poll() implementation to use
ZMQ_FD and ZMQ_EVENTS.
Also fix some corner cases: We should not pollute revents with
unrequested events, and we don't need to poll on ZMQ_FD at all
if a pollitem with no events set was passed in.
Rewrite zmq_poll() to use ZMQ_FD and ZMQ_EVENTS introduced on the
wip-shutdown branch. Only do the poll()-based version of zmq_poll (), the
select()-based version will not compile at the moment.
Sockets may now be migrated between OS threads; sockets may not be used by
more than one thread at any time. To migrate a socket to another thread the
caller must ensure that a full memory barrier is called before using the
socket from the target thread.
The new zmq_close() semantics implement the behaviour discussed at:
http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004244.html
Specifically, zmq_close() is now deterministic and while it still returns
immediately, it does not discard any data that may still be queued for
sending. Further, zmq_term() will now block until all outstanding data has
been sent.
TODO: Many bugs have been introduced, needs testing. Further, SO_LINGER or
an equivalent mechanism (possibly a configurable timeout to zmq_term())
needs to be implemented.
definitions as aliases, to be removed in release 3.0. Also renamed the source
files implementing these two socket types. This change does not break existing
applications nor bindings, but allows us to fix the documentation and user guide
now, rather than keeping the old (confusing) names.
This reverts part of commit 84e0c7991a9b316ed571533abc628cc1175750a3 to get
correct ZMQ_HWM semantics with XREQ sockets:
When sending a message to an XREQ socket, the underlying pipe is selected in
a round-robin fashion. If an underlying pipe is full it is skipped. If there
are no underlying pipes, or all underlying pipes are full then zmq_send()
shall block or return EAGAIN, depending on whether or not the call is blocking.
Messages are never dropped.
The msgs_written variable keeps track how many complete
messages have been written so far. The rollback operation drops all
fragments of the last incomplete message so it shouldn't
change this variable at all.
