This is because as it adds the 255th element at a node it attempts to calculate
the count member var which is an unsigned char via count = (255 -0) + 1; and
pass the result to realloc. Unfortunately the result is zero and realloc returns
null; the prefix_tree asserts. I have fixed it by making the count an unsigned
short.
I was hitting an issue with an SCL enabled STL library in connection with the
way select_t::loop was erasing retired fd's. The problem as identified by the
SCL assertion was that by the time the iterator given to the erase method was
called it was considered invalid by the library. I am not sure this isn't just
a "quirk" of the MSVC STL library as the other code looks valid to me as well.
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.
