Merge pull request #314 from ianbarber/master

Small patch to instantiate clock_t once
fix bug in zmq::tcp_address_t::resolve_interface() where all resolved interface ip's overwrited by 0.0.0.0
Merge pull request #315 from shripchenko/master

fix bug in zmq::tcp_address_t::resolve_interface() where resolved interface ip overwrited by 0.0.0.0
Fixed issue LIBZMQ-358
implement zmq_unbind(),zmq_disconnect(), zmq->sock->getsockopt(ZMQ_LAST_ENDPOINT_ID)
Merge pull request #317 from shripchenko/master

implement zmq_unbind(),zmq_disconnect(), zmq->sock->getsockopt(ZMQ_LAST_ENDPOINT_ID)
Merge pull request #316 from pieterh/master

Fixed issue #358
2nd try wuth sock->unbind() and sock->disconnect(). now with blackjack and const char*'s
fixes for

make[2]: Entering directory `/home/laotse/src/abs/zeromq-git/src/libzmq-build/src'
  CXX    libzmq_la-address.lo
address.cpp: In destructor 'zmq::address_t::~address_t()':
address.cpp:41:29: error: deleting object of polymorphic class type 'zmq::tcp_address_t' which has non-virtual destructor might cause undefined behaviour [-Werror=delete-non-virtual-dtor]
cc1plus: all warnings being treated as errors
Merge pull request #318 from shripchenko/master

2nd try wuth sock->unbind() and sock->disconnect(). now with const char*'s argument
stupid bug. I feel ashamed ^)
small wording change
Merge pull request #319 from shripchenko/master

fix for: [zeromq-dev] head builds again but two failing tests
spaces deleted
added zmq_unbind() / zmq_disconnect() test script.
it works but rises very serious questions.

Please add license header by your choice.
This file for 99% resemble crossroads-io/tests/shutdown.cpp
fixes for zmq_unbind() / zmq_disconnect() usage corner cases

1. when we call zmq_bind()/zmq_connect() to create endpoint
we send ourselfs(through launch_child()) command to process_own(endpoint)
(and add it to own_t::owned)
in the application thread we could call zmq_unbind() / zmq_disconnect() _BEFORE_
we run process_own() in ZMQ thread and in this situation we will be unable to find it in
own_t::owned. in other words own_t::owned.find(endpoint) will not be deleted but it will be deleted from
socket_base_t::endpoints.

2. when you zmq_unbind() the lisnening TCP/IPC socket was terminated only in destructor...
so the whole ZMQ_LINGER time listening TCP/IPC socket was able to accept() new connections
but unable to handle them.

this all geting even worse since unfortunately zmq has a bug and '*_listener_t' object not terminated
untill the socket's zmq_close().
AT LEAST FOR PUSH SOCKETS.
Everything is ok for SUB sockets.

Easy to reproduce without my fix:

zmq_socket(PUSH)
zmq_bind(tcp);
// connect to  it from PULL socket
zmq_unbind(tcp);

sleep(forever)

// netstat -anp | grep 'tcp listening socket'

With my fix you could see that after zmq_unbind(tcp) all previously connected tcp sessions
will not be finished untill the zmq_close(socket) regardless of ZMQ_LINGER value.

(*_listener_t terminates all owned session_base_t(connect=false) and they call pipe_t::terminate()
which in turn should call session_base_t::terminated() but this never happens)
Merge pull request #320 from shripchenko/master

ZMQ BUG FOUND + fixes for zmq_unbind() / zmq_disconnect() usage corner cases
add process_commands() to the beginning of zmq_connect() and zmq_bind()

I believe there was a conception that zmq_connect() and zmq_bind() will be called
only at the socket creation time and therefore don't need it.
Now it is not true anymore.
Merge pull request #321 from shripchenko/master

add process_commands() to the beginning of zmq_connect() and zmq_bind()
Implement atomic operations for armv7a

This commit implements atomic operations for the armv7a architecture
using gcc inline assembly.  This offers higher performance compared to
pthread mutexes.

Tested on an am3517 evm, clocked at 600MHz:

./inproc_thr 200 1000000
------------------------
53-60K messages / sec, pthread mutexes
73-90K messages / sec, assembly atomic ops

./inproc_lat 200 1000000
------------------------
average latency: 42.234 [us], pthread mutexes
average latency: 35.496 [us], assembly atomic ops