From 2afba0085f9a2fc007208c31ca2457c5e0b49a5c Mon Sep 17 00:00:00 2001 From: Luca Boccassi Date: Fri, 30 Dec 2016 23:27:56 +0100 Subject: [PATCH] Problem: documentation does not warn about ZMQ_EVENT_ALL and new events Solution: add a note pointing out that when new events are added the ZMQ_EVENT_ALL mask will start returning them, so applications that can't handle that transparently should not use it and instead pick only the event types they want. Creating a new event type and having monitors with ZMQ_EVENT_ALL return them will not be considered a backward incompatible change even though the flow of events will change. --- doc/zmq_socket_monitor.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/zmq_socket_monitor.txt b/doc/zmq_socket_monitor.txt index 3d37b54f..bd7837bb 100644 --- a/doc/zmq_socket_monitor.txt +++ b/doc/zmq_socket_monitor.txt @@ -23,7 +23,10 @@ your own 'ZMQ_PAIR' socket, and connect that to the endpoint. The 'events' argument is a bitmask of the socket events you wish to monitor, see 'Supported events' below. To monitor all events, use the -event value ZMQ_EVENT_ALL. +event value ZMQ_EVENT_ALL. NOTE: as new events are added, the catch-all +value will start returning them. An application that relies on a strict +and fixed sequence of events must not use ZMQ_EVENT_ALL in order to +guarantee compatibility with future versions. Each event is sent as two frames. The first frame contains an event number (16 bits), and an event value (32 bits) that provides additional