Skip to content

Releases: axelriet/libzmq

AzCNS Snap 3/21/2024

21 Mar 20:26
@axelriet axelriet
AzCNS_Snap
74d2e7c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
AzCNS Snap 3/21/2024 Latest
Latest

AzCNS Snap 3/21/2024

Assets 2
Loading

Libzmq-4.3.6.0-Redist-Jan-03-2024

03 Jan 18:29
@axelriet axelriet
Libzmq-4.3.6.0-Redist-Jan-03-2024
8676ffc
Compare
Choose a tag to compare
Libzmq-4.3.6.0-Redist-Jan-03-2024 Pre-release
Pre-release

This is a fork of libzmq post 4.3.5.0, with enhancements. It incorporate all fixes made to the mainline 4.3.6.0 as of 03-Jan-2024.

This build requires the VC runtime: https://aka.ms/vs/17/release/vc_redist.x64.exe

This build requires a CPU with AVX instructions, e.g. Sandy Bridge (2011) or newer, AMD Bulldozer (2011), Jaguar (2013) or newer, as well as Windows 7 SP1 or later, or Windows Server 2008 R2 SP1 with KB2568088, or later. In short it should run fine on anything less than ten years old.

Sources for this fork: https://github.com/axelriet/libzmq
Original project: https://github.com/zeromq/libzmq

Enhancements (compared to the baseline libzmq 4.3.6.0 as of 03-Jan-2024, about 160 commits ahead)

  • The Vsm threshold is increased from 33 bytes to 40 bytes. This enable more small messages to be transmitted with less CPU overhead and better performance due to reduced heap contention. This benefits inproc transfers more than ipc or over-the-network. The drawback is the threshold for long group names has been reduced from 14 characters to 7 characters, so make sure 1) your group names (if you use these) are at most 7 characters + null and your message payload is at most 40 bytes.

  • A new zmq_set_custom_msg_allocator() function has been added allowing users to substitute their own memory allocator for message content. See zmq.h for details, as well as the new remote_thr_ca test app. This is an advanced feature to be used in rare situations where (for example) a fixed-size allocator could perform better than the CRT heap, or the TBB scalable allocator, see below.

  • The send functions for protocols using message aggregation tries to club messages into a larger buffer a little more aggressively. The impact is small, if any, but is saves a couple of context switches when sending small messages in quick bursts.

  • Support for the Microsoft HvSocket transport has been added. This allows VM<->Host communication, as well as Container<->Host communication pretty much like the existing VMCI support does for VmWare VMs. See test_pubsub for addressing details but essentially "hyperv://localhost:1234" does what you think it does, and faster than ipc. "hyperv://children:1234" and "hyperv://parent:1234" is how the host listen to children VMs/Containers and how the guests contact their host/parent. Incidentally, HvSocket is the fastest IPC mechanism for ZeroMQ on Windows.

  • This fork is built with support for Intel's Scalable Allocator. This is a better/faster heap than the default CRT heap (malloc/free) for high-contention scenarios. This comes with a small runtime library, tbbmalloc.dll, that must sit next to libzmq.dll. Inproc message throughput benefits the most, reaching the 10M messages/sec ballpark for messages below the vsm threshold of 40 bytes in this build.

Support for Linux's Vsock has been added in experimental and untested form (yet) - This is essentially Linux's version of VMCI and HvSocket for KVM. VSock also works with VMCI and HvSocket with some restrictions so it might be the transport of choice from Linux VMs and Containers to their Windows or Linux host. The support is compiled in this Windows-only DLL for testing purpose, e.g. if you somehow have a VSock-enabled Windows guest OS in a VM.

The DLL name is libzmq.dll - This build gets rid of the naming madness used in the original project (which does not cover half the ground it should anyway, e.g. AMD vs ARM.)

The DLL is production-signed (by me) using a trusted DigiCert authenticode certificate. As such the DLL wil pass all AV and malware screening. The tbbmalloc dll is also prod-signed by Intel. The DLL should be a binary-drop-in replacement for the original one.

For devs, the public header (zmq.h) is now heavily annotated with SAL2 annotations. Compiling with /analyze on MSVC or Intel C++ will enable advanced diagnostics enabling you to consume the library in a safer and correct way.

I included the debug symbols. These don't need to ship, but you need them to make sense of crash dumps of your app. Always build with /Zi and /DEBUG and religiously archive the .PDB of everything you ship as they must match your binaries exactly.

With them you can do post-mortem symbolic debugging with call stacks that make sense. Dumps can be created on-demand using Task Manager for hung apps (Details, right-click the process, Create dump file) of from the command-line using Sysinternal's ProcDump (https://learn.microsoft.com/en-us/sysinternals/downloads/procdump) or programmatically using MiniDumpWriteDump() - for example from a top-level SEH handler. Learn to use crash dumps to your advantage to debug hung apps, access violations and fatal app exits through RaiseException() or __fastfail().

Feedback welcome,
Have fun!

Axel

Disclosure: I'm a Windows kernel dev now working on Azure Core. Any opinion expressed above are mine and do not imply any endorsement from my employer.

Loading