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.
This commit is contained in:
Luca Boccassi 2016-12-30 23:27:56 +01:00
parent c0e2bc4ef9
commit 2afba0085f

View File

@ -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