Solution: The Coverity Static Code Analyzer was used on libzmq code and found
many issues with uninitialized member variables, some redefinition of variables
hidding previous instances of same variable name and a couple of functions
where return values were not checked, even though all other occurrences were
checked (e.g. init_size() return).
See issue #1608.
This is an old issue with Windows 7. The effect is that we see a latency
ramp on the first 500 messages.
* The ramp is unaffected by message size.
* Sleeping up to 100msec between sends has no effect except to switch
off ZeroMQ batching so making the ramp more visible.
* After 500 messages, latency falls back down to ~10-40 usec.
* Over inproc:// the ramp happens when we use the signaler class.
* Client-server over inproc:// does not show the ramp.
* Client-server over tcp:// shows a similar ramp.
We know that the signaller is using TCP on Windows. We can 'prime' the
connection by doing 500 dummy sends. This potentially causes new sockets
to be delayed on creation, which is not a good solution.
Note that the signaller sends zero-byte messages. This may also be
confusing TCP.
Solution: flood the receive buffer when creating a new FD pair; send a
1M buffer and discard it.
Fixes#1608
In real world usage, there have been reported signaler failures where the
eventfd read() or socket recv() system call in signaler::recv() fails,
despite having made a prior successful signaler::wait() call.
this patch creates a signaler::recv_failable() method that allows
unreadable eventfd / socket to return an error without asserting.
Of course people still "can" distributed the sources under the
LGPLv3. However we provide COPYING.LESSER with additional grants.
Solution: specify these grants in the header of each source file.
This is a silly assertion that causes problems if libzmq.dll is
called in some esoteric ways.
Solution: if the shutdown code detects WSANOTINITIALISED, then
exit silently.
Fixes#1377Fixes#1144
Updated:
src/signaler.cpp: Add close_wait_ms() static function to loop
when receiving EAGAIN in response to close(), with ms long
sleeps, up to a maximum limit (default 2000ms == 2 seconds);
used in signaler_t::~signaler_t() destructor.
The decision about the poller mechanism to use (select, poll, ...)
was done twice: once by the build system and once by the code in
poller.hpp. As the build-system can actually detect the mechanisms
available, prefer that result to the hard coded defaults in
poller.hpp.
At the same time, remove the duplicate detection of select() vs.
poll()-variant from proxy.cpp, signaler.cpp and zmq.cpp.
This patch has not been tested on many build platforms: especially
the cmake build needs testing / patching. For the other builds,
hard code the result as these these are all Windows platforms.
Copyrights had become ads for Sustrik's corporate sponsors, going against the original
agreement to share copyrights with the community (that agreement was: one line stating
iMatix copyright + one reference to AUTHORS file). The proliferation of corporate ads
is also unfair to the many individual authors. I've removed ALL corporate title from
the source files so the copyright statements can now be centralized in AUTHORS and
source files can be properly updated on an annual basis.
- Windows CE does not manage security attributes (no SetSecurityDescriptorDacl(), SetEvent (NULL, xxx) ...)
- Windows CE does not inheritance of sockets for child process (SetHandleInformation ((HANDLE) *w_, HANDLE_FLAG_INHERIT...)
- see comments about story "Porting ZeroMQ to Windows Mobile" on webpage http://www.zeromq.org/story:5
By assigning a SECURITY_DESCRIPTOR to the event we gain the ability to
share it between service and console programs. We also added
EVENT_MODIFY_STATE as a requirement to OpenEvent so we can SetEvent later
in the method.
