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

feature: support for add/remove single flag in event set #53

Open
KarthikNedunchezhiyan opened this issue Nov 9, 2020 · 3 comments
Open

Comments

@KarthikNedunchezhiyan
Copy link
Contributor

It would be helpful if the event-manager support add/remove individual flag from the existing one (instead of whole) or support for getting previously registered flags.

Some use case is we send more data via vsock (async mode) so, we need to add EventSet::OUT flag additionally whenever we experience WouldBlock error.

@alexandruag
Copy link
Collaborator

This makes sense, but I'm not sure what the right prioritization is :-s Does the status quo cause significant pain for the use cases you have in mind? (I guess the current alternative is for the subscriber to keep track of the event flags and then process and use mod to change the entire set)

@KarthikNedunchezhiyan
Copy link
Contributor Author

I guess the current alternative is for the subscriber to keep track of the event flags and then process and use mod to change the entire set

@alexandruag it is possible but in our case we have lots of events under single subscribers. each time we add/update the event_set of fd, we need to update the subscriber code also (to track of recently updated event_set for a fd).

We have lots of individual subscriber code, so we need to perform above operation on all subscribers. which makes a code duplication. To avoid code duplication we need to write a wrapper over event-manager so, that the wrapper will keep track of latest event_set for all fd associated.

IMO, The above complexity will be removed if this is natively supported by event-manager.

@alexandruag
Copy link
Collaborator

Sure, then a good starting point seems to be if, like you mentioned, the manager kept track of registered events and was able to provide this info. I'll start thinking about the implications and a potential solution, but most likely won't make significant progress until the start of next week :( Happy to hear if you already have any ideas here.

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