Feat/monitor poll #414

lp35 · 2020-05-14T12:40:41Z

This MR improve monitor_t class by addressing #381 and #109.

This lead to better application design and allows the same thread to do both monitoring and retrieving messages from the monitored socket, thus avoiding clunky code with threads joining everywhere.

lp35 · 2020-05-14T12:46:19Z

Additional information:

get_event() is not compatible with zmq version < 4
if legacy compatibility with 3.x can be dropped for check_event(), the new get_event() method can be used to avoid duplicated code in check_event()

sigiesec

Thanks for the extensions, I think these will be really useful.

Please see my comments on individual issues.

Also, please remember to reformat all commits with clang-format.

Most of the travis builds are failing right now, could you give them a look and fix them, please?

sigiesec · 2020-05-22T08:35:19Z

zmq.hpp

@@ -2224,6 +2224,53 @@ class monitor_t
        on_monitor_started();
    }

+#if ZMQ_VERSION_MAJOR >= 4
+    bool get_event(zmq_event_t& eventMsg, std::string& address, zmq::recv_flags flags = zmq::recv_flags::none)


I am not sure about the signature of this method. What about

std::optional<std::pair<zmq_event_t, std::string>> get_event(zmq::recv_flags flags = zmq::recv_flags::none)

(This requires C++17 this way, but we can also do this with the fallback to detail::trivial_optional as done for other types)

This removes the ambiguity of whether the original value of eventMsg and address are used and in what cases they are modified.

Ok, I'm not very familiar with std::optional and will try to implement this way

sigiesec · 2020-05-22T08:36:23Z

zmq.hpp

+                if (zmq_errno() == ETERM || zmq_errno() == EAGAIN)
+                    return false;


Why does this also returns false on ETERM? There's no way to distinguish EAGAIN and ETERM this way, and this seems inconsistent with the behavior of zmq::socket_t::recv.

Check https://github.com/zeromq/cppzmq/blob/master/zmq.hpp#L2274.

I just kept same behaviour implemented in check_event(). If this is not mandatory, I can just throw an exception and not use a std::optionnal as described above, but just std::pair<>

Hm, yes, that's right. It's inconsistent one way or the other, but I think the behaviour of zmq::socket_t::recv is the appropriate one.

what we should implement in this case? Maybe we shall throw an exception?

sigiesec · 2020-05-22T08:36:48Z

zmq.hpp

+
+        if (rc == -1)
+        {
+            if (zmq_errno() == ETERM)


Again, why does this return false rather than throwing?

See my comment above

sigiesec · 2020-05-22T08:37:51Z

zmq.hpp

+
+        {
+            message_t msg;
+            int rc = zmq_msg_recv(msg.handle(), _monitor_socket.handle(),


Can't this use _monitor_socket.recv?

Of course, but then it is not possible to use the same behaviour as the old check_event. Otherwise I will need to use a try catch statement

sigiesec · 2020-05-22T08:38:10Z

zmq.hpp

+        }
+
+        message_t addrMsg;
+        int rc = zmq_msg_recv(addrMsg.handle(), _monitor_socket.handle(),


Like above, can't this use _monitor_socket.recv?

See prev comment

Thanks for the extensions, I think these will be really useful.

Please see my comments on individual issues.

Also, please remember to reformat all commits with clang-format.

Could you add this to the contribution guidelines of the project?

Most of the travis builds are failing right now, could you give them a look and fix them, please?

I don't like to put effort on something that will be not merged. I was waiting for a green thumb before putting more work on this, as I did not asked anyone about the design of this PR ;)

Thanks for reviewing, will try to solve all of those next week. BR

sigiesec · 2020-05-22T08:39:57Z

tests/monitor.cpp

+                { monitor.handle(), 0, ZMQ_POLLIN, 0 },
+            };
+
+            zmq::poll(&items[0], 1, 100);


Please use the overload taking std::chrono::milliseconds.

sigiesec · 2020-05-22T08:44:04Z

zmq.hpp

+    operator void *() ZMQ_NOTHROW { return handle(); }
+
+    operator void const *() const ZMQ_NOTHROW { return handle(); }


I'd rather not add these operators. socket_t and context_t have them because they are direct correspondents of the underlying C data structures. But that's not the case here, and it's not obvious that a cast to void* returns the monitor socket handle.

sigiesec · 2020-05-22T08:46:07Z

zmq.hpp

+    ZMQ_NODISCARD void *handle() ZMQ_NOTHROW { return _monitor_socket.handle(); }
+
+    ZMQ_NODISCARD const void *handle() const ZMQ_NOTHROW { return _monitor_socket.handle(); }


Similar to the comment above, I'd use more specific names for these functions. We are in monitor_t, so monitor is probably redundant, but i'd use socket_handle.

Also, the const overload should be removed. There are no functions in the C zmq API that accept a const void* socket. I now they exist for other classes, but that's rather a legacy.

sigiesec · 2020-05-22T08:49:16Z

zmq.hpp

@@ -2232,6 +2232,8 @@ class monitor_t

    ZMQ_NODISCARD const void *handle() const ZMQ_NOTHROW { return _monitor_socket.handle(); }

+    operator socket_ref() ZMQ_NOTHROW { return (zmq::socket_ref) _monitor_socket; }


Again, I'd not add an operator here but rather a named socket() member function. Actually, then the handle/socket_handle function is not necessary at all, since its handle can be accessed through the socket_ref.

sigiesec · 2020-05-22T08:49:47Z

zmq.hpp

@@ -2414,6 +2414,15 @@ class monitor_t
        _socket = socket_ref();
    }
 #endif
+
+    void close() ZMQ_NOTHROW


Please also add a test for this.

Will be done.

sigiesec · 2020-06-19T16:09:01Z

Any update on this? Is there anything you need to address the comments? Sorry I didn't get back until now, but from reading your responses I assumed that most things are clear and undisputed.

lp35 · 2020-06-22T12:04:41Z

Hi,

Thanks for pinging back. I'm struggling to find some time to fix those issues. I will try to do my best in the next couple of weeks.

Cheers

lp35 added 4 commits May 14, 2020 14:36

monitor: add get_event() method

a4570b1

monitor: add compatibility with zmq::poll()

78dab5d

monitor: add compatibility with zmq::poller_t

3aa80d0

monitor: expose close() method to public

c2298e8

sigiesec requested changes May 22, 2020

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat/monitor poll #414

Feat/monitor poll #414

lp35 commented May 14, 2020

lp35 commented May 14, 2020

sigiesec left a comment

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec Jun 19, 2020

lp35 Aug 19, 2021

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec May 22, 2020

lp35 May 22, 2020 •

edited

Loading

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec May 22, 2020

lp35 May 22, 2020

sigiesec commented Jun 19, 2020

lp35 commented Jun 22, 2020

		if (zmq_errno() == ETERM \|\| zmq_errno() == EAGAIN)
		return false;

		operator void *() ZMQ_NOTHROW { return handle(); }

		operator void const *() const ZMQ_NOTHROW { return handle(); }

		ZMQ_NODISCARD void *handle() ZMQ_NOTHROW { return _monitor_socket.handle(); }

		ZMQ_NODISCARD const void *handle() const ZMQ_NOTHROW { return _monitor_socket.handle(); }

		@@ -2232,6 +2232,8 @@ class monitor_t

		ZMQ_NODISCARD const void *handle() const ZMQ_NOTHROW { return _monitor_socket.handle(); }

		operator socket_ref() ZMQ_NOTHROW { return (zmq::socket_ref) _monitor_socket; }

Feat/monitor poll #414

Are you sure you want to change the base?

Feat/monitor poll #414

Conversation

lp35 commented May 14, 2020

lp35 commented May 14, 2020

sigiesec left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lp35 May 22, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sigiesec commented Jun 19, 2020

lp35 commented Jun 22, 2020

lp35 May 22, 2020 •

edited

Loading