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

Composing event sources #207

Open
vikigenius opened this issue Aug 26, 2024 · 1 comment
Open

Composing event sources #207

vikigenius opened this issue Aug 26, 2024 · 1 comment

Comments

@vikigenius
Copy link

I am trying to create an event source for Unix domain sockets to use in an IPC Server. I tried to follow the zmq example in the book and have a working solution. But I have some design questions. Becasue there are some differences in the event sources between a ZMQ socket and a Unix socket.

With unix sockets the event sources are split into two. The listener that accepts connections. And the UnixStream that sends and receives messages.

Is it better to keep these sources separate or have a composed EventSource like this

pub struct IPCSource {
    socket_source: calloop::generic::Generic<calloop::generic::FdWrapper<UnixListener>>,
    connections: HashMap<&str, calloop::generic::Generic<calloop::generic::FdWrapper<UnixStream>>>,
}

Writ now I have two separate Event Sources one for the Listener and one for the UnixStream (there will be multiple UnixStreams because of multiple connections).

But I am wondering if I can gain some benefit by composing them like this or something similar?

@elinorbgr
Copy link
Member

If having multiple sources works well for you, I don't think you'd gain much by composing everything into a single event source. So unless you think doing so would significantly improve your program structure, I'd recommend against it.

Having a single source with a dynamically changing number of underlying fds would mean it'd end up being regularly reregistered, which would be rather wasteful.

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

No branches or pull requests

2 participants