This patch fixes a bug in the message encoder which was
responsible for computing incorrect message offset.
The bug affected PGM receiver making it unable to
decode inital messages.
File decoder.cpp does not compile with Visual C++ 2008:
1>c:\tmp\libzmq\src\decoder.cpp(117) : warning C4003: not enough actual parameters for macro 'max'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2589: '(' : illegal token on right side of '::'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2059: syntax error : '::'
1>c:\tmp\libzmq\src\decoder.cpp(117) : error C2143: syntax error : missing ';' before '{'
This error is caused by the precense of a macro 'max' when including
'windows.h'. To solve this problem, the preprocessor macro /DNOMINMAX must
be specified.
shadowing a real EAGAIN return value from the OS. This caused later
assertions of "Invalid argument" in stream_engine.cpp when it attempted to
use a socket which was not connected.
I also add EINTR to mean EINPROGRESS, as per the POSIX and FreeBSD
documentation which specifies that a connect() call interrupted due to a
signal will complete asynchronously.
Signed-off-by: Martin Lucina <martin@lucina.net>
When more then one peer connected to a ZMQ_PAIR socket,
an application aborted due to assertion failure.
This patch changes the ZMQ_PAIR socket behaviour so that
it rejects any further connection requests.
Before this patch, the stream engine terminated itself
whenever it had detected an IO error. If this happened
when sending a message, the engine lost all
in-flight messages, messages waiting to be decoded,
and the last decoded message that had not been accepted,
if there was one.
The new behaviour is to terminate the engine only after
the input error has been detected and the last decoded
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.
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)
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
