Is it possible to add an event handling to ZeroMQ

2019-05-26 07:59发布

问题:

I have created two unrelated daemon processes in C in Linux Ubuntu. These processes are in the sleeping mode, they only wake up when the data is received, and perform the action implemented in the signal handler and again sleep.

I have implemented this communication using SIGNAL IPC and message queue. Before sending the message, I send the signal SIGUSR1 and then send the data, and I wrote the signal handler for SIGUSR1 to perform required action.

I would like to implement the same way of communication using ZeroMQ and I have been reading their guide to find out, whether ZeroMQ has any kind of event handling or notification method for other process, when the data has arrived ( for C language ).

I have referred the following link too:

Does ZeroMQ have a notification/callback event/message for when data arrives?

But still I am doubtful.

Does ZeroMQ notify or trigger other process some event, when a new data has been sent ( I do not want to wait or poll() until the data arrives, instead my daemon process would be sleeping and when the data arrives, it would execute its handler and sleep again )?

It would be great if someone can help / suggest on this.

回答1:

No.

In as-is state, ZeroMQ does not implement either a trigger nor a callback.

Why?

Because the core Messaging mindset is to use Queues, not to disturb the flow of the processes, unless the processes themselves find it feasible to ask the Queue ( be it using a smart way, testing via .poll(), or in a dumb way, by a straight call to .recv( ZMQ_NOBLOCK ) ), if there are any messages ready and waiting for their post-processing and will then start to .recv() them from the ZeroMQ-side thread(s) and its resources & process them on their own process' footprint and work-flow.


But POSIX SIGNAL-s mechanics change The Rules of the Game:

Given the facts about the ZeroMQ per-se, the SIGUSR1 can deliver an independent ( just context-of-use aligned ) "Out-of-Band" signal to the receiving-process, that the sender-process has just marshaled some communication to be processed, sent and delivered down the road, so the receiving process may activate and follow the tools & methods for .recv()-ing data from the ZeroMQ delivery-path, in spite of the fact, that ZeroMQ mechanics does not provide call-back methods on its own.

So in this sense, that even the imperative language implementation of the algorithm becomes context-of-use aware about the success / failure of the last ZeroMQ call, the O/S POSIX signalling layer ( fully independent of the distributed ZeroMQ messaging / signalling delivery infrastructure ) can provide such sought means of inter-process coordination aimed at working among even sleeping / daemon instances of process-networks under test.