There are a number of patterns described in the guide, you might be able to use one of them.

As far as I can tell this is the intended behaviour of the PUB socket type:

When a ZMQ_PUB socket enters the mute state due to having reached the high water mark for a subscriber, then any messages that would be sent to the subscriber in question shall instead be dropped until the mute state ends.

(http://api.zeromq.org/4-3:zmq-socket#toc10)

If you need more reliable delivery with fan-out, I think you need to roll your own - I'm building something like this with client/server right now, albeit with TCP and not PGM.

/* Send SIGINT to this program, "main exit" can't print. Reopen zloop_set_verbose line, "main exit" can print. Why? */

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <czmq.h>

int timer_cb(zloop_t* loop, int timer_id, void* args) { printf("timer_id=%d\n", timer_id); return 0; }

int main(int argc, char* argv[]) { zloop_t* loop = zloop_new(); int timer_id = zloop_timer(loop, 1000, 0, timer_cb, NULL); // zloop_set_verbose(loop, true); zloop_start(loop); printf("main exit\n"); zloop_destroy(&loop); sleep(10); return 0; }

Right, thank you.

This fixes build under BSD. Tested with OpenBSD-6.4 and FreeBSD-11.3.

ZeroMQ works with MINGW and pthread conditional variables if pthread mutexes are used. POSIX conditional variables require POSIX mutexes, but ZeroMQ unconditionally uses WIN32 critital sections even when configured with pthread conditional variables. This of course does not work. This patch fixes the build so that MINGW builds do not use WIN32 critical sections and instead use POSIX mutexes when configured with pthread conditional variables.

Tested with:

 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ ../libzmq/configure --host=x86_64-w64-mingw32 --prefix=`pwd`/stage --enable-debug --disable-Werror --enable-libunwind=no   --with-cv-impl=pthread --enable-libbsd=no

x86_64-w64-mingw32-gcc --version

   x86_64-w64-mingw32-gcc (GCC) 10.2.0.....

Issue description

zeromq 4.3.3 fails to build with mingw, where zeromq 4.3.2 was fine:

tests/testutil.hpp:105:15: error: conflicting declaration of C function ‘int closesocket(int)’
  105 | #define close closesocket
      |               ^~~~~~~~~~~
In file included from tests/../src/windows.hpp:54,
                 from tests/testutil.hpp:43,
                 from tests/testutil_unity.hpp:34,
                 from tests/testutil_unity.cpp:29:
/usr/share/mingw-w64/include/winsock2.h:1005:34: note: previous declaration ‘int closesocket(SOCKET)’
 1005 |   WINSOCK_API_LINKAGE int WSAAPI closesocket(SOCKET s);
      |                                  ^~~~~~~~~~~

Everything builds fine if I delete the:

#define close closesocket

referenced above, but I don't whether this is some hack needed for other Windows compilers (e.g. MSVC). It does seem like a pretty dangerous thing to define in a header, though.

Since that define was there in 4.3.2, I am not sure why this started failing in 4.3.3: perhaps some test includes shuffled around?

(Looking at it more closely, it seems testutil.hpp has quite a bit of other Windows-related cruft that isn't needed at all since it has already included ../src/windows.hpp).

Environment

• libzmq version 4.3.3
• OS: Debian linux
• $ x86_64-w64-mingw32-gcc --version x86_64-w64-mingw32-gcc (GCC) 10-posix 20200525

There is a macro that redefines close to closesocket, but then close is later defined in unistd.h which is included in testutil_unity.cpp which then causes the regular close() prototype to be defined with the new function name closesocket which does not match the signature of the original closesocket in winsock2.h from the toolchain.

We can work around this issue, by making sure that unistd.h is included before the macro is defined. HMM> Yes macro substitution is the root of evil.

This fixes build under BSD. Tested with OpenBSD-6.4 and FreeBSD-11.3.

Pull request submitted #4172 .

This needs #4172 to build the tests.

ZeroMQ works and MINGW and pthread conditional variables if pthread mutexes are used. POSIX conditional variables require POSIX mutexes, but ZeroMQ unconditionally uses WIN32 critital sections even when configured with pthread conditional variables. This of course does not work. This patch fixes the build so that MINGW builds do not use WIN32 critical sections and instead use POSIX mutexes when configured with pthread conditional variables.

Tested with:

 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ ../libzmq/configure --host=x86_64-w64-mingw32 --prefix=`pwd`/stage --enable-debug --disable-Werror --enable-libunwind=no   --with-cv-impl=pthread --enable-libbsd=no

x86_64-w64-mingw32-gcc --version

   x86_64-w64-mingw32-gcc (GCC) 10.2.0.....

NOTE: This should resolve issue #4044

There is a macro that redefines close to closesocket, but then close is later defined in unistd.h which is included in testutil_unity.cpp which then causes the regular close() prototype to be defined with the new function name closesocket which does not match the signature of the original closesocket in winsock2.h from the toolchain.

We can work around this issue, by making sure that unistd.h is included before the macro is defined. HMM> Yes macro substitution is the root of evil.

if you use verbose zsys_init will be called. That probably explains the difference.