Commit 2afba008 authored by Luca Boccassi's avatar Luca Boccassi

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.
parent c0e2bc4e
...@@ -23,7 +23,10 @@ your own 'ZMQ_PAIR' socket, and connect that to the endpoint. ...@@ -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 The 'events' argument is a bitmask of the socket events you wish to
monitor, see 'Supported events' below. To monitor all events, use the 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 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 number (16 bits), and an event value (32 bits) that provides additional
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment