Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

epoll: always retrieve events from triggered sockets #88

Merged
merged 1 commit into from Sep 16, 2023

Conversation

jagerman
Copy link
Member

The epoll approach from #87 sometimes hangs a socket: apparently the call to getting the ZMQ events off a socket can have internal ZMQ side effects (see libzmq issue 3641 for more), so make sure we always call it on triggered sockets when using epoll.

This fixes a hang in the epoll code that triggers on heavy, bursty
connections (such as the live SPNS APNs notifier).

It turns out that side-effects of processing our sockets could leave
other sockets (that we processed earlier in the loop) in a
needs-attention state which we might not notice if we go back to
epoll_wait right away.  zmq::poll apparently takes care of this (and so
is safe to re-poll even in this state), but when we are using epoll we
need to worry about it by always checking for zmq events (which itself
has side effects) and, if we get any, re-enter the loop body immediately
*without* polling to deal with them.
@jagerman jagerman merged commit dc7fb35 into oxen-io:dev Sep 16, 2023
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants