- option to set number of zmq threads on the command line for local_thr
- option to set number of zmq_threads and workers in remote_thr
- option to set SND/RCV buffer sizes on command line
- option to set whether to PUSH/PULL on command line
- option to set to use zmq_recv or zmq_msg for transfer on command line
- better timing function
- corrected and improved throughput reporting
- HWM and DELAY socket options
- New ZMQ_STATIC flag to enable "libzmq.lib" Windows static library (or "libzmq_d.lib" in Debug mode).
- ZMQ_STATIC needs also to be defined by projects using static linking against "libzmq.lib"
- New StaticDebug & StaticRelease configurations for libzmq Win32 projects under MSVC 2008 & 2010
- Tested with Visual Studio 2008 Express under Windows 7, and Visual Studio 2010 Express under Windows 8.
- 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
- when compiling for Windows CE, a C++ project must define the preprocessor definitions: UNDER_CE=$(CEVersion),_WIN32_WCE=$(CEVersion)
- choosing the "_WIN32_CE" form for uniformization with "_WIN32" and "_WIN32_WINNT" already used in libzmq (boost is using both forms)
- see http://msdn.microsoft.com/en-us/library/ee479161(v=winembedded.60).aspx
MSVC build fails with linking errors for unresolved symbols SetSecurityDescriptorDacl and InitializeSecurityDescriptor in signaler.obj
Adding the relevant link library (Advapi32.lib) to VCLinkerTool fixes this (tested MSVC2010 on XP and Win7)
When we send a large message, the message can be splitted into two chunks.
One is in the encoder buffer and the other is the zero-copy pointer.
The session could get the term before the last chunk is sent.
* Removed or truncated sleeps so the tests run faster
* Removed dependencies on zmq_utils
* Rewrote a few tests that were confusing
* Minor code cleanups
Until now, zmq_poll always allocates the poll items on the heap.
Now, small item sets, up to ZMQ_POLLITEMS_DFLT, are stack allocated
and only larger sets are allocated on the heap.
