Solution: use pthread API to set the name. For now call every thread
"ZMQ b/g thread". Would be nice to number the I/O threads and name
explicitly the reaper thread, but in reality a bit of internal API
churn would be necessary, so perhaps it's not worth it.
This is useful when debugging a process with many threads.
Solution: add a zmq_assert to check if the ephemeral sockets created
to drain the queue of pending inproc connecting sockets was allocated
successfully.
Solution: check if the connecting inproc socket has been closed
before trying to send the identity.
Otherwise the pipe will be in waiting_for_delimiter state causing
writes to fail and the connect to assert when the context is being
torn down and the pending inproc connects are resolved.
Add test case that covers this behaviour.
libsodium calls abort() when /dev/urandom can't be found
even if one creates ZeroMQ context before calling chroot()[1].
This happens because crypto gets initialized on handshake,
and at that moment the process is already chroot'ed.
Solution: initialize cryptographic libraries in ctx
randombytes_close() is already there in the destructor.
[1] https://download.libsodium.org/doc/usage/index.html
- they have no copyright / license statement
- they are in some randomish directory structure
- they are a mix of postable and non-portable files
- they do not conform to conditional compile environment
Overall, it makes it rather more work than needed, in build scripts.
Solution: clean up tweetnacl sauce.
- merged code into single tweetnacl.c and .h
- standard copyright header, DJB to AUTHORS
- moved into src/ along with all other source files
- all system and conditional compilation hidden in these files
- thus, they can be compiled and packaged in all cases
- ZMQ_USE_TWEETNACL is set when we're using built-in tweetnacl
- HAVE_LIBSODIUM is set when we're using external libsodium
It's unclear which we need and in the source code, conditional code
treats tweetnacl as a subclass of libsodium, which is inaccurate.
Solution: redesign the configure/cmake API for this:
* tweetnacl is present by default and cannot be enabled
* libsodium can be enabled using --with-libsodium, which replaces
the built-in tweetnacl
* CURVE encryption can be disabled entirely using --enable-curve=no
The macros we define in platform.hpp are:
ZMQ_HAVE_CURVE 1 // When CURVE is enabled
HAVE_LIBSODIUM 1 // When we are using libsodium
HAVE_TWEETNACL 1 // When we're using tweetnacl (default)
As of this patch, the default build of libzmq always has CURVE
security, and always uses tweetnacl.
And I'm on a reasonably sized laptop. I think allocating INT_MAX
memory is dangerous in a test case.
Solution: expose this as a context option. I've used ZMQ_MAX_MSGSZ
and documented it and implemented the API. However I don't know how
to get the parent context for a socket, so the code in zmq.cpp is
still unfinished.
VMCI transport allows fast communication between the Host
and a virtual machine, between virtual machines on the same host,
and within a virtual machine (like IPC).
It requires VMware to be installed on the host and Guest Additions
to be installed on a guest.
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.
Solution: set defaults back to infinity, and add new context
option, ZMQ_BLOCKY that the user can set to false to get a
less surprising behavior on context termination. Eg.
zmq_ctx_set (ctx, ZMQ_BLOCKY, false);
When Curve authentication is used, libsodium opens a file
descriptor to /dev/urandom to generate random bytes. When
the ZMQ context terminates, it should ensure that file gets
closed.
Well, not gibberish, but 2^31 on Linux, which is useless. The code
should probably use getrlimit on Linux and other calls depending on
the system. For now I've set the ceiling at 64K.
The new options allows querying the maximum allowed number of sockets.
This is system dependent and cannot be encoded in the include file as a
preprocessor macro: for ZMQ_USE_SELECT, this depends on the FD_SETSIZE
macro at time of library compilation, not at time of include file use.
