The test suite uses the standard automake support. Tests are always built,
but run only when you do a "make check".

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.

Dunno where those <TAB>s came from...

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.

Add some basic documentation for XREQ/XREP socket types, including
a brief description of the most common use case (REQ -> XREP) and (XREQ ->
REP).

Function returning unsigned long int cannot return (-1)