Poll monitoring sockets about cppzmq

[a4z]

I have just split the blocking function without breaking the existing interface.
b838563
now you can use monitor_t non blocking in the same thread as the monitored, or any other, socket.

the socket is currently not public, but I have a similar use case like you describe and might adopt it to be able to poll on the monitor and other socket in one poll item. But before I do this I would like to measure if this has a performance advantage over having 2 poll items.

Implicit conversion, like you suggest, is imho not like it should be in C++ since C++ should be type safe and strong typed.
also, I do not think that the sockets currently stored as void pointers it the best idea, so I think they should be typed.

[lp35]

Hey,

I'm also missing this feature. Why not making monitor_t inherit from socket_t?

IMHO, this would be a better RAII design (see #381), and force the user to configure the monitor in the constructor instead of using init() method.

[sigiesec]

I'm also missing this feature. Why not making monitor_t inherit from socket_t?

I think it is not necessary, it would be sufficient if a method were added to monitor_t that provides accessing to its _monitor_socket, IIUC. Composition should generally be preferred over inheritance.

IMHO, this would be a better RAII design (see #381), and force the user to configure the monitor in the constructor instead of using init() method.

I agree that the init method is not nice, however bear in mind that any changes need to be backwards-compatible. It is conceivable to add a new class under a different name that is designed without an ìnitmethod and declaremonitor_t` deprecated.

[dietelTiMaMi]

I added a Pull Request (#612) to expose the monitor socket for using it with an active poller from the hppaddon.cpp
the check_event() method was split to prevent polling for the same event twice.
The api stays fully backward compatible.