A Go interface to ZeroMQ version 4

zmq4 version: 4b5b0725b5d36cef61e2744bd7c93067180e3edf (latest) zeromq-4.1.3 (latest) libsodium: 1.0.3 (latest)

There appears to be a race condition with the AuthStop() and Term() functions. Steps to reproduce the problem:

1. Run the below code
2. Wait 2 seconds and ctrl-c.
3. It will hang within 3-5 tries.
4. A second ctrl-c exists the program.

Comment-out the AuthStop() and Term() code below and the program exits cleanly upon ctrl-c.

Workaround: Do not use AuthStop() and Term(). The program will end just fine.

package main

import (
        "log"
        "os"
        "os/signal"
        "syscall"
        "time"

        z "github.com/pebbe/zmq4"
)

func main() {
        us_public_key := "VVPVGyASr0?}lkRR28ULJj}N4Ut-NC>Q?qZ6!F3N"
        us_secret_key := "lU9<Y]^0CG*gI6N7Gyx.Sb/Q5:SX=[3moZv>B<c9"
        them_public_key := "K!y%@qX/ukA=Tw0E+#Lt.]k{Xu9yzZFf66TK&L@R"
        defer log.Println("After Term(), stopped")
        defer z.Term() // Comment-out to avoid hang
        defer log.Println("before Term()")
        z.AuthStart()
        defer z.AuthStop() // Comment-out to avoid hang
        defer log.Println("before AuthStop()")
        z.AuthCurveAdd("*", them_public_key)
        defer z.AuthCurveRemoveAll("*")
        sock, _ := z.NewSocket(z.ROUTER)
        defer sock.Close()
        sock.SetIdentity("a")
        sock.ClientAuthCurve(them_public_key, us_public_key, us_secret_key)
        connect := "tcp://127.0.0.1:5000"
        sock.SetReconnectIvl(time.Second * 1)
        sock.SetReconnectIvlMax(time.Second * 1)
        sock.Connect(connect)
        defer sock.Disconnect(connect)
        defer sock.SetLinger(0)
        sigc := make(chan os.Signal, 10)
        signal.Notify(sigc, os.Interrupt, syscall.SIGTERM)
        log.Println("Waiting ..")
        <-time.After(3 * time.Second)
        log.Println("ok to ctrl-c")
        <-sigc
        log.Println("received sigc")
}

Also hangs with zeromq-3.2.5.

Thank you for creating the golang library. Works great.

Hi Peter,

I'm lost trying to figure this out for days, I'm probably missing the point, can you point me in the right direction?

I want to send/recv messages concurrently with a ROUTER. The code below describes how it's done logically. The code either polls or sends a message. If TIMEOUT is big, say 10s, outgoing messages are blocked. If TIMEOUT is small, say 10us, processor usage goes 100%. Now what?

func Listen() {
    poller := zmq.NewPoller()
    poller.Add(socket, zmq.POLLIN)

    for {
        polled, _ := poller.Poll(TIMEOUT)
        handleIncoming(polled)

        sendAnyMessages()
    }
}

Any hint is appreciated.

I have a Golang application that utilizes pebbe/zmq4 and I'd love to be able to run it in Alpine Linux due to the much smaller container size. However, I get the following error:

apk update
apk install gcc pkgconfig zeromq-dev
go run main.go
# github.com/pebbe/zmq4
In file included from /go/src/github.com/pebbe/zmq4/ctxoptions_unix.go:6:0:
/usr/include/zmq.h:46:19: fatal error: errno.h: No such file or directory
compilation terminated.

I'm using the golang:1.5-alpine container available on Docker Hub.

I am trying to setup a Pub-Sub network with a proxy (like in the doc). However after a short period of time (about 1 minute) the proxy dies:

socket operation on non-socket

       ctx, err := zmq.NewContext()
        // frontend
	s, err := ctx.NewSocket(zmq.XSUB)
	if err != nil {
		return fmt.Errorf("NewSocket: %s", err)
	}
	if err = s.Bind("inproc://input"); err != nil {
		return fmt.Errorf("Bind: %s", err)
	}
	// backend
	p, err := zmq.NewSocket(zmq.XPUB)
	if err != nil {
		return fmt.Errorf("NewSocket: %s", err)
	}
	if err = p.Bind("tcp://*:5555"); err != nil {
		return fmt.Errorf("Bind: %s", err)
	}
	// listen
	l, err := ctx.NewSocket(zmq.PAIR)
	if err != nil {
		return fmt.Errorf("NewSocket: %s", err)
	}
	if err = l.Connect("inproc://pipe"); err != nil {
		return fmt.Errorf("Connect: %s", err)
	}
	if err := zmq.Proxy(s, p, l); err != nil {
		log.Fatal("Proxy is dead: ", err)
	}

And then all my publishers (each in their own thread) share the same context (ctx) and publish on inproc.

Hi pebbe, I am inclined to say that something is broken with the way pebbe/zqm4 is checking for zmq lib versions or I am really overlooking something here. any help is appreciated.

please have a look at this. I will give you the whole workflow I do here.

let's start with a clean go environment:

~  $ rm -rf gocode/src/github.com/pebbe/
~  $ rm -rf gocode/pkg/
~  $ go get -u github.com/pebbe/zmq4
# pkg-config --cflags libzmq
Package libzmq was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzmq.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libzmq' found
pkg-config: exit status 1
~  $ 

so far so good. zmq4 is missing libzmq package. which is right. because I have none installed yet. so let's do that:

~  $ sudo apt-cache policy libczmq-dev
libczmq-dev:
  Installed: (none)
  Candidate: 4.1.0
  Version table:
     4.1.0 500
        500 http://download.opensuse.org/repositories/network:/messaging:/zeromq:/release-stable/Debian_9.0 ./ Packages
     3.0.2-5 500
        500 http://de.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
~  $ 

notice that I am downloading from official zmq repository for debian9.0/ubuntu like said on http://czmq.zeromq.org/page:get-the-software

now let's check if we really have no libzmq libs installed:

~  $ ll /usr/lib/x86_64-linux-gnu/libzmq*
ls: cannot access '/usr/lib/x86_64-linux-gnu/libzmq*': No such file or directory

now let's install libczmq-dev finally:

~  $ sudo apt-get install libczmq-dev
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  libczmq4 libnorm1 libsodium18 libsystemd-dev libzmq3-dev libzmq5
The following NEW packages will be installed:
  libczmq-dev libczmq4 libnorm1 libsodium18 libsystemd-dev libzmq3-dev libzmq5
0 upgraded, 7 newly installed, 0 to remove and 178 not upgraded.
Need to get 0 B/1,331 kB of archives.
After this operation, 5,340 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Selecting previously unselected package libnorm1:amd64.
(Reading database ... 237362 files and directories currently installed.)
Preparing to unpack .../libnorm1_1.5r6+dfsg1-1_amd64.deb ...
Unpacking libnorm1:amd64 (1.5r6+dfsg1-1) ...
Selecting previously unselected package libsodium18:amd64.
Preparing to unpack .../libsodium18_1.0.8-5_amd64.deb ...
Unpacking libsodium18:amd64 (1.0.8-5) ...
Selecting previously unselected package libzmq5:amd64.
Preparing to unpack .../libzmq5_4.2.3_amd64.deb ...
Unpacking libzmq5:amd64 (4.2.3) ...
Selecting previously unselected package libzmq3-dev:amd64.
Preparing to unpack .../libzmq3-dev_4.2.3_amd64.deb ...
Unpacking libzmq3-dev:amd64 (4.2.3) ...
Selecting previously unselected package libsystemd-dev:amd64.
Preparing to unpack .../libsystemd-dev_229-4ubuntu21.1_amd64.deb ...
Unpacking libsystemd-dev:amd64 (229-4ubuntu21.1) ...
Selecting previously unselected package libczmq4.
Preparing to unpack .../libczmq4_4.1.0_amd64.deb ...
Unpacking libczmq4 (4.1.0) ...
Selecting previously unselected package libczmq-dev.
Preparing to unpack .../libczmq-dev_4.1.0_amd64.deb ...
Unpacking libczmq-dev (4.1.0) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up libnorm1:amd64 (1.5r6+dfsg1-1) ...
Setting up libsodium18:amd64 (1.0.8-5) ...
Setting up libzmq5:amd64 (4.2.3) ...
Setting up libzmq3-dev:amd64 (4.2.3) ...
Setting up libsystemd-dev:amd64 (229-4ubuntu21.1) ...
Setting up libczmq4 (4.1.0) ...
Setting up libczmq-dev (4.1.0) ...
Processing triggers for libc-bin (2.23-0ubuntu10) ...
~  $

check again:

~  $ ll /usr/lib/x86_64-linux-gnu/libzmq*
-rw-r--r-- 1 root root 1.8M Dec 31  2014 /usr/lib/x86_64-linux-gnu/libzmq.a
lrwxrwxrwx 1 root root   15 Dec 31  2014 /usr/lib/x86_64-linux-gnu/libzmq.so -> libzmq.so.5.1.3
lrwxrwxrwx 1 root root   15 Dec 31  2014 /usr/lib/x86_64-linux-gnu/libzmq.so.5 -> libzmq.so.5.1.3
-rw-r--r-- 1 root root 596K Dec 31  2014 /usr/lib/x86_64-linux-gnu/libzmq.so.5.1.3
~  $ 

5.1.3 stands for version 4.2.3 here.

now let's see what pkgconfig would say to pebbe/zmq4 if pebbe/zmq4 were to ask for it when we go get this repository:

~  $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/libzmq.pc 
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include

Name: libzmq
Description: 0MQ c++ library
Version: 4.2.3
Libs: -L${libdir} -lzmq
Libs.private: -lstdc++  -lsodium -lpgm -lpthread -lm -lnorm
Cflags: -I${includedir} 
~  $ 

notice: it says you will find the libzmq packages/libs in /usr/lib/x86_64-linux-gnu/ with version 4.2.3.

so far so good. let's continue to go get this repository finally:

~  $ go get -u github.com/pebbe/zmq4
~  $ 

worked. now let's continue to build our go application:

~/gocode/src/github.com/omani/lol/cmd (master [uncommited!]) $ go build -o lol main.go
~/gocode/src/github.com/omani/lol/cmd (master [uncommited!]) $ 

worked. now let's run the just created binary:

~/gocode/src/github.com/omani/lol/cmd (master [uncommited!]) $ ./lol

USAGE:
   lol -c=<string> --identity=<string>
                    [--debug]
   lol --help
   lol --version

Use 'lol --help' to get detailed information about options and examples of usage.
~/gocode/src/github.com/omani/lol/cmd (master [uncommited!]) $ 

so at first sight, it seems to work. but that's just an illusion. this is only flags doing it's job and returning due to missing arguments. we never really ran the app. so now let's give the application some working cli arguments to see what really happens:

~/gocode/src/github.com/omani/lol/cmd (master [uncommited!]) $ ./lol -c ~/lol.toml -identity lol01 -debug
2018/03/10 15:27:57 zmq4 was installed with ZeroMQ version 4.2.4, but the application links with version 4.2.3
~/gocode/src/github.com/omani/lol/cmd (master [uncommited!]) $ 

there you go. the app does not start because it's complaining about zmq.

now here is my question: How can this even be? As you can see we installed libczmq version 4.2.3. and all it's dependencies for version 4.2.3. Why should this ever happen that zmq4 is thinking we had version 4.2.4 during the time we ran go get github.com/pebbe/zmq4? You see what pkgconfig said which version we have installed and I assume that is the same information zmq4 is getting.

so where does version 4.2.4 come from?

thanks.

Hi,

I am seeing lot's of errors "interrupted system call" on a typical broker implementation when compiling with the current go version 1.14 and running on linux/amd64. According to the release notes this is sort of expected. My question is, if we can expect this to be handled in the library in the future or if we need to implement a loop around each and every zmq call retrying it in case of EINTR?

The code looks something like this: (results and pub are *zmq.Socket):

for {
    // receive a result
    msg, err := results.RecvMessageBytes(0)
    total++
    if err != nil {
      log.Printf("Error receiving a result: %s", err)
      errorcount++
      continue
    }
    m := msg[0]
    // publish it (it should have already the topic prepended)
    _, err = pub.SendBytes(m, 0)
    if err != nil {
      log.Printf("Error publishing message: %s", err)
      errorcount++
      // fall through, so we can still push it to another socket
    }
...

I am running in a docker container in case that matters. Compiling with go 1.13 does not show the issue.

Thank you!

--Matthias

➜  http-test  go get github.com/pebbe/zmq4
# github.com/pebbe/zmq4
could not determine kind of name for C.ZMQ_CURVE_PUBLICKEY
could not determine kind of name for C.ZMQ_CURVE_SECRETKEY
could not determine kind of name for C.ZMQ_CURVE_SERVERKEY
could not determine kind of name for C.ZMQ_GSSAPI_PLAINTEXT
could not determine kind of name for C.ZMQ_GSSAPI_PRINCIPAL
could not determine kind of name for C.ZMQ_GSSAPI_SERVER
could not determine kind of name for C.ZMQ_GSSAPI_SERVICE_PRINCIPAL
could not determine kind of name for C.ZMQ_HANDSHAKE_IVL
could not determine kind of name for C.ZMQ_IMMEDIATE
could not determine kind of name for C.ZMQ_IPV6
could not determine kind of name for C.ZMQ_LAST_ENDPOINT
could not determine kind of name for C.ZMQ_MAXMSGSIZE
could not determine kind of name for C.ZMQ_MECHANISM
could not determine kind of name for C.ZMQ_MULTICAST_HOPS
could not determine kind of name for C.ZMQ_PLAIN_PASSWORD
could not determine kind of name for C.ZMQ_PLAIN_SERVER
could not determine kind of name for C.ZMQ_PLAIN_USERNAME
could not determine kind of name for C.ZMQ_RCVHWM
could not determine kind of name for C.ZMQ_SNDHWM
could not determine kind of name for C.ZMQ_SOCKS_PROXY
could not determine kind of name for C.ZMQ_TCP_KEEPALIVE
could not determine kind of name for C.ZMQ_TCP_KEEPALIVE_CNT
could not determine kind of name for C.ZMQ_TCP_KEEPALIVE_IDLE
could not determine kind of name for C.ZMQ_TCP_KEEPALIVE_INTVL
could not determine kind of name for C.ZMQ_TOS
could not determine kind of name for C.ZMQ_ZAP_DOMAIN


➜  http-test  go version
go version go1.4 linux/amd64


➜  http-test  gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 

➜  http-test  uname -a
Linux wkc-pc 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

This bug report is posted as recommended by the good people who have replied to my question here: https://groups.google.com/forum/#!topic/Golang-nuts/TeZwtP6z98w

socket.RecvMessage() is getting interrupted with EINTR for some reason and according to the golang-nuts replies, this should be hidden from the user and automatically retried.

I am trying to build a static binary and I get the following error

CGO_ENABLED=0 go get -a -ldflags '-s' github.com/pebbe/zmq4
# github.com/pebbe/zmq4
/go/src/github.com/pebbe/zmq4/auth.go:564: undefined: Socket
/go/src/github.com/pebbe/zmq4/auth.go:573: undefined: Socket
/go/src/github.com/pebbe/zmq4/auth.go:582: undefined: Socket
/go/src/github.com/pebbe/zmq4/auth.go:594: undefined: Socket
/go/src/github.com/pebbe/zmq4/auth.go:603: undefined: Socket
/go/src/github.com/pebbe/zmq4/reactor.go:10: undefined: State
/go/src/github.com/pebbe/zmq4/reactor.go:11: undefined: State

when i cycle call NewContext()->NewSocket()->socket.close()->context.term(), some times later, this problem appears and the program crash。Or maybe， the progress block in term(). Or maybe,it crash in term() with "Assertion failed: ok (mailbox.cpp:82)".

We've been using your library to build a thin inter-service communication layer on top of zmq. Recently when testing more extensively we ran into a major issue with this lib which forced us to migrate to alecthomas's lib. Now when he officially put it in maintenance mode I thought we should work this out together:

The issue is when connecting a "client" to multiple "servers", there is only one zmq.Context created (in init()). We have clients that connects to multiple backing services via different sockets but since the init() is only run once it only creates one context which makes client connections to multiple backends impossible. At least that's what our investigations found, and switching to alecthomas's which lets you manually create contexts made it work.

To clarify: It works just fine to bind one socket to multiple endpoints, the issue is when creating multiple sockets. Maybe there already is a solution already but otherwise I suggest something like this not to break the API:

• Introduce the concept of Context (exported) and basically support creating Contexts and a few methods for creating socket(s) in that context (we could probably borrow some code from alecthomas here).
• Keep the current implementation of a "global" context for use cases not dealing with contexts and also (mainly) not to break current API.

I would like to understand the best practice for gracefully exiting a poll loop when using this library (or zmq poll in general)

I have the following crude example, which works fine : Is there a more elegant way to do it ?

I realize there is only 1 socket in this example but more will be added.

Eish:
	for {

		sockets, _ := poller.Poll(time.Second * 3)

		for _, socket := range sockets {
			switch s := socket.Socket; s {
			case sub1:
				address, err := s.Recv(0)
				if err != nil {
					log.Errorf("Error receiving zmq message(1) : %v", err)
					continue
				}
				if msg, err := s.Recv(0); err != nil {
					log.Errorf("Error receiving zmq message(2) : %v", err)
					continue
				} else {
					mess := string(msg)
					fmt.Print("Received message from " + address + " channel.")
					fmt.Printf("%+v\n", mess)
				}
			}

		}

		select {
		case <-ctx.Done():
			log.Infof("Exiting zmq.")
			break Eish
		case <-time.After(time.Millisecond * 1):
		}

	}

Installed zeromq using brew and using go1.18.4

brew install pkg-config zeromq

➜ pkg-config --modversion libzmq
4.3.4
➜ go env CGO_ENABLED
1

Tried to build a package that imports "github.com/pebbe/zmq4"

ld: warning: ignoring file /opt/homebrew/Cellar/zeromq/4.3.4/lib/libzmq.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64
Undefined symbols for architecture x86_64:
  "_zmq_bind", referenced from:
      _zmq4_bind in _x009.o
  "_zmq_close", referenced from:
      _zmq4_close in _x009.o
  "_zmq_connect", referenced from:
      _zmq4_connect in _x009.o
  "_zmq_ctx_get", referenced from:
      _zmq4_ctx_get in _x009.o
  "_zmq_ctx_new", referenced from:
      _zmq4_ctx_new in _x009.o
  "_zmq_ctx_set", referenced from:
      _zmq4_ctx_set in _x009.o
  "_zmq_ctx_term", referenced from:
      _zmq4_ctx_term in _x009.o
  "_zmq_curve_keypair", referenced from:
      _zmq4_curve_keypair in _x009.o
  "_zmq_curve_public", referenced from:
      _zmq4_curve_public in _x009.o
  "_zmq_disconnect", referenced from:
      _zmq4_disconnect in _x009.o
  "_zmq_getsockopt", referenced from:
      _zmq4_getsockopt in _x009.o
  "_zmq_has", referenced from:
      __cgo_623c834d1dc5_Cfunc_zmq_has in _x010.o
     (maybe you meant: __cgo_623c834d1dc5_Cfunc_zmq_has)
  "_zmq_msg_close", referenced from:
      __cgo_623c834d1dc5_Cfunc_zmq_msg_close in _x010.o
     (maybe you meant: __cgo_623c834d1dc5_Cfunc_zmq_msg_close)
  "_zmq_msg_data", referenced from:
      _zmq4_get_event40 in _x010.o
      _zmq4_get_event41 in _x010.o
      __cgo_623c834d1dc5_Cfunc_zmq4_get_event40 in _x010.o
      __cgo_623c834d1dc5_Cfunc_zmq4_get_event41 in _x010.o
      __cgo_623c834d1dc5_Cfunc_zmq_msg_data in _x010.o
     (maybe you meant: __cgo_623c834d1dc5_Cfunc_zmq_msg_data)
  "_zmq_msg_gets", referenced from:
      _zmq4_msg_gets in _x009.o
  "_zmq_msg_init", referenced from:
      __cgo_623c834d1dc5_Cfunc_zmq_msg_init in _x010.o
     (maybe you meant: __cgo_623c834d1dc5_Cfunc_zmq_msg_init)
  "_zmq_msg_recv", referenced from:
      _zmq4_msg_recv in _x009.o
  "_zmq_poll", referenced from:
      _zmq4_poll in _x009.o
  "_zmq_proxy", referenced from:
      _zmq4_proxy in _x009.o
  "_zmq_proxy_steerable", referenced from:
      _zmq4_proxy_steerable in _x009.o
  "_zmq_send", referenced from:
      _zmq4_send in _x009.o
  "_zmq_setsockopt", referenced from:
      _zmq4_setsockopt in _x009.o
  "_zmq_socket", referenced from:
      _zmq4_socket in _x009.o
  "_zmq_socket_monitor", referenced from:
      _zmq4_socket_monitor in _x009.o
  "_zmq_strerror", referenced from:
      __cgo_623c834d1dc5_Cfunc_zmq_strerror in _x004.o
     (maybe you meant: __cgo_623c834d1dc5_Cfunc_zmq_strerror)
  "_zmq_unbind", referenced from:
      _zmq4_unbind in _x009.o
  "_zmq_version", referenced from:
      __cgo_623c834d1dc5_Cfunc_zmq_version in _x010.o
     (maybe you meant: __cgo_623c834d1dc5_Cfunc_zmq_version)
  "_zmq_z85_decode", referenced from:
      __cgo_623c834d1dc5_Cfunc_zmq_z85_decode in _x010.o
     (maybe you meant: __cgo_623c834d1dc5_Cfunc_zmq_z85_decode)
  "_zmq_z85_encode", referenced from:
      __cgo_623c834d1dc5_Cfunc_zmq_z85_encode in _x010.o
     (maybe you meant: __cgo_623c834d1dc5_Cfunc_zmq_z85_encode)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Am I missing a dependency or have I gone wrong somewhere in configuring things? Would appreciate any push in the right direction.

@pebbe , Hey,this is not an issue, hoping to understand and start a discussion if it merits so. Did not find a forum for this.

My questions and concerns: https://stackoverflow.com/questions/72847547/high-cpu-usage-when-using-pebbe-zmq-proxy-at-high-message-rates

Quote from https://pkg.go.dev/github.com/pebbe/zmq4 :

func (*Socket) Monitor ¶
func (soc *Socket) Monitor(addr string, events Event) error
Register a monitoring callback.

See: http://api.zeromq.org/4-1:zmq-socket-monitor#toc2

WARNING: Closing a context with a monitoring callback will lead to random crashes. This is a bug in the ZeroMQ library. The monitoring callback has the same context as the socket it was created for.

It would be helpful if the comment could be expanded to explain and give instructions on how to avoid random crashes.

Is the context an explicit Go context type, or does "context" mean the socket being monitored?

Does the developer need to call Close() on the PAIR monitor socket before calling Close() on the socket that is being monitored? (i.e. the problem occurs when the monitor socket is active but the socket being monitored is closed?)

Will the bug be triggered by runs of the example code, in which the monitor goroutine only exits the RecvEvent loop when RecvEvent returns err!=nil, or is the example code ok to use as a base for actual monitoring?

Is there an upstream reference for this bug? Or is it a "working as designed" issue, where developers are expected to write code in a certain way to not trigger a crash?

I would like to use zmq4 (https://github.com/pebbe/zmq4) in Go Programming Language on a Windows system. This need to have ZeroMQ (libzmq) installed (https://zeromq.org/download/ or https://github.com/zeromq/libzmq). Unfortunately, I can not find a way to install libzmq on Windows. Can anyone help me?