Updated:
builds/zos/README.md: Updated with portability notes resulting
from building zeromq/libzmq/master as of 2014-07-23 on z/OS
UNIX System Services.
Current z/OS UNIX status: all expected tests pass, except
"test_proxy", which hangs and times out.
Updated:
src/thread.cpp: On older z/OS UNIX System Services,
pthread_{get,set}schedparam is not present (searching the
Internet suggests it may be present in later version than
the one being used for z/OS UNIX System Services porting).
Make zmq::thread_t::setSchedulingParameters() a no-op on
z/OS UNIX System Services.
NOTE: pthread_{get,set}schedparam appear to have been introduced
by POSIX.1-2001 or IEEE 1003.1-2004 so may not be universally
available, and thus more platforms may need this "no-op" treatment.
Updated:
builds/zos/runtests: Extract tests to run from tests/Makefile.am
at runtime, rather than hard coding tests list (to simplfy
later maintenance). test_*_tipc is excluded as BUILD_TIPC is
not defined on z/OS UNIX System Services. XFAIL_TESTS are also
excluded, following current logic in tests/Makefile.am
Updated:
builds/zos/cxxall: Defines ZMQ_HAVE_ZOS for platform portability;
define ZMQ_USE_POLL _instead_ of ZMQ_FORCE_POLL, due to change
in src/poller.hpp since ZeroMQ 4.0.x branch
Updated:
src/metdata.hpp: Remove explicit "const" from key of std::map<>
because the key is implicitly const already (see
http://en.cppreference.com/w/cpp/container/map and
http://www.cplusplus.com/reference/map/map/).
On some platforms (such as z/OS UNIX System Services) explicitly
declaring the map key as "const" causes template expansion errors
as it tries to create separate allocators for "const const std::string"
and "const std::string" only to find that they clash. (Presumably
some compilers collapse these into one earlier.)
There are no template expansion errors if the map key is left to be
implicitly const.
Updated:
builds/zos/README.md: Outlined process to transfer source from
GitHub to z/OS UNIX System Services, including character set
conversion for the source
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.
Updated:
README.md: describes process of building/using DLL
makelibzmq: Build DLL as well as static library (unless BUILD_DLL=false)
maketests: Dynamically link to ../src/libzmq.so if present
runtests: Explicitly place ../src at start of LIBPATH
makeclean: Also remove files created for DLL
cxxall: Bumped updated date to reflect last edit
builds/zos includes:
README.md: Overview of z/OS UNIX System Services port (Markdown)
makelibzmq: Compile src/*.cpp and make libzmq.a
maketests: Compile tests/*.cpp and make test_* executables
runtests: Run tests/test_* executables and report results
makeclean: Remove built files
zc++: /bin/c++ wrapper supplying required build arguments
cxxall: run zc++ for all *.cpp files in directory
platform.hpp: pre-generated (and edited) src/platform.hpp for z/OS
test_fork.cpp: updated tests/test_fork.cpp that completes on z/OS
Users who need e.g. zmq_curve_keypair() have to remember to include
zmq_utils.h, which is counter-intuitive. The whole library should be
represented by a single include file.
Solution: merge all contents of zmq_utils.h into zmq.h, and deprecate
zmq_utils.h. Existing apps can continue unchanged. New apps can ignore
zmq_utils.h completely.
Rationale: In a real-time environment it is sometime mandatory to tune
threads priority and scheduling policy. This is required by our users
who mixes real-time and server threads within
the same process. It's not planned to support this on non-pthread
platforms (e.g. Windows).
Since https://github.com/zeromq/libzmq/commit/350a1a, TCP addresses
get resolved asynchronously, so zmq_connect no longer returned an
error on incorrect addresses.
This is troublesome since we rely on some error checking to catch
blatant errors.
Solution add some upfront syntax checking that catches at least the
obvious kinds of errors (invalid characters, wrong or missing port
number).
This is still raw and experimental.
To connect through a SOCKS proxy, set ZMQ_SOCKS_PROXY socket option on
socket before issuing a connect call, e.g.:
zmq_setsockopt (s, ZMQ_SOCKS_PROXY,
"127.0.0.1:22222", strlen ("127.0.0.1:22222"));
zmq_connect (s, "tcp://127.0.0.1:5555");
Known limitations:
- only SOCKS version 5 supported
- authentication not supported
- new option is still undocumented
As libzmq is compiled with optional transports and security mechanisms,
there is no clean way for applications to determine what capabilities
are actually available in a given libzmq instance.
Solution: provide an API specifically for capability reporting. The
zmq_has () method is meant to be open ended. It accepts a string so
that we can add arbitrary capabilities without breaking existing
applications.
zmq.h also defines ZMQ_HAS_CAPABILITIES when this method is provided.
Solution: use same approach as for libsodium/CURVE, i.e. return EINVAL
if the library isn't present when libzmq builds, and the application
still tries to use these options in zmq_getsockopt/setsockopt.
