- 30 Dec, 2016 2 commits
-
-
Luca Boccassi authored
Solution: add them to the event monitor manpage
-
Luca Boccassi authored
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.
-
- 14 Sep, 2015 1 commit
-
-
Elliot Saba authored
Without this change, a segmentation fault is likely to occur when using the proposed snippet of code, as `*address[size]` is equivalent to `*(address[size])`, not `(*address)[size]` as clearly intended.
-
- 08 Nov, 2014 1 commit
-
-
J.T. Conklin authored
-
- 28 Apr, 2014 1 commit
-
-
Pieter Hintjens authored
Specifically: * zmq_event_t should not be used internally in libzmq, it was meant to be an outward facing structure. * In 4.x, zmq_event_t does not correspond to monitor events, so I removed the structure entirely. * man page for zmq_socket_monitor is incomplete and the example code was particularly nasty. * test_monitor.cpp needed rewriting, it was not clean.
-
- 15 Apr, 2013 1 commit
-
-
Pieter Hintjens authored
contributors and doesn't reflect the real process. I've taken out all named authors and referred to the contribution policy. Hopefully this will improve the contributions to the man pages.
-
- 12 Mar, 2013 1 commit
-
-
Pieter Hintjens authored
-
- 08 Mar, 2013 1 commit
-
-
Guido Goldstein authored
-
- 08 Jan, 2013 1 commit
-
-
Pieter Hintjens authored
-
- 21 Sep, 2012 1 commit
-
-
Lourens Naudé authored
Significantly reworked the monitoring infrastructure with a more granular per socket API and to play well with monitoring endpoints in application threads
-