Some confusion about using nng together with select/poll/epoll on linux #1864
-
|
I've been using ZeroMQ as the communication framework for my applications for quite some time, but recently I've been considering migrating to nng. I find nng's design impressive as it offers greater flexibility for applications. I've looked at the async example in the demo and understood that nng uses threads to handle messages, enabling parallelism in the message processing process. In my previous programs, I used the poll mode, and for now, I don't plan to rewrite the existing logic using asynchronous callbacks. I still want to keep the poll mode. So in nng, I found a substitute called nn_poll, but it seems this API exists for compatibility with nanomsg and is not recommended for use. If I use it together with select/poll/epoll, there's a potential issue: nng will read the messages from the socket and store them in its internal message queue. If at this point, I use select/poll/epoll to check the socket's readability, it will likely return that there are no messages to read, which could cause the program to block unless new data arrives at that moment. Is the scenario described above possible? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
What you want is to use the file descriptors that will be created by NNG_OPT_SENDFD and NNG_OPT_RECVFD. These are pollable file descriptors (you poll for readability -- never actually do you read or write them), and they will be readable when the socket can send or recv. Note that this design comes at a cost, but that's true for nanomsg and ZeroMQ as well... you're doing extra system calls to do this synchronization. But it may be simpler if you need to integrate into an existing select/poll/epoll loop. |
Beta Was this translation helpful? Give feedback.
What you want is to use the file descriptors that will be created by NNG_OPT_SENDFD and NNG_OPT_RECVFD. These are pollable file descriptors (you poll for readability -- never actually do you read or write them), and they will be readable when the socket can send or recv.
Note that this design comes at a cost, but that's true for nanomsg and ZeroMQ as well... you're doing extra system calls to do this synchronization. But it may be simpler if you need to integrate into an existing select/poll/epoll loop.