| Age | Commit message (Collapse) | Author |
|---|
|
Fixes the build on NetBSD where the compiler complains about casting NULL
to (int).
Signed-off-by: Martin Lucina <mato@kotelna.sk>
|
|
- RAND_bytes function resides in crypto library
- pollfd on AIX used 'reqevents' instead of events and 'retnevents'
instead of 'revents'
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
|
|
eats signal
Added block boolean var to second process_commands() invocation for blocking sockets
instead of always using true. This prevents the process_commands() call from hanging
when a message is received with an empty queue after the call to xrecv() but
prior to the initial call to process_commands() invoked when ++ticks == inbound_poll_rate.
Signed-off-by: Marc Rossi <mrossi19@gmail.com>
|
|
With SunStudio's implementation of STL basic_string constructor
doesn't accept NULL as a parameter even though size of string
is set to zero. Fixed.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
|
|
The comment about memory ownership in uuid_t::to_string
was misleading as on most platforms the buffer is a field
of the object;
The string allocated in UuidToString() wasn't properly freed
with RpcStringFree()
Signed-off-by: Taras Shpot <taras.shpot@eleks.com>
|
|
Macro ZMQ_VERSION represents the current version of 0MQ
Macro ZMQ_MAKE_VERSION(major,minor,patch) allows to create
a representation of the specified version.
The versions can be compared using simple <, >, ==, etc.
operators.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
|
|
|
|
|
|
fixed
|
|
latency peak may occur -- fixed
|
|
|
|
|
|
|
|
|
|
Ensure that 0MQ does not attempt to call select() on more than FD_SETSIZE
file descriptors.
|
|
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.
|
|
Function returning unsigned long int cannot return (-1)
|
|
http://github.com/zeromq/zeromq2/issues#issue/46
Invalid messages are now discarded silently, instead of causing an assertion
failure.
|
|
* Fixed zmq_term, zmq_socket, zmq_close, zmq_setsockopt,
* zmq_getsockopt, zmq_bind, zmq_connect, zmq_send,
* zmq_recv, zmq_poll, zmq_device, zmq_stopwatch_stop
* Updated Reference Manual for these methods
|
|
* zmq_term
* zmq_socket
* zmq_close
* zmq_setsockopt
* zmq_getsockopt
* zmq_bind
* zmq_connect
* zmq_send
* zmq_recv
* zmq_poll
* zmq_device
* zmq_stopwatch_stop
|
|
|
|
This patch restarts the send() or recv() inside zmq::signaler_t if the call fails
due to EINTR.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
