-
Notifications
You must be signed in to change notification settings - Fork 185
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
feat(iroh-net): Removeable discovery #2827
Conversation
this creates a map of discovery services that can be used to get the discovery services and/or dynamically modify them. The downside is that it now requires a RwLock, and there is a potential for a deadlock if people write a very convoluted discovery service...
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/2827/docs/iroh/ Last updated: 2024-11-20T10:48:44Z |
if you just store an |
Yeah, but then I still have to make a copy of the Vec that contains them. I already had a version where I was using a smallvec for this, but using a persistent data structure seems like a better solution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rather like this, maybe open the PR and ask @ramfox for input as well?
What I do wonder is how feasible it is to add this functionality to the existing ConcurrentDiscovery
instead of creating a new struct that will eventually replace it?
.field("max_id", &self.max_id) | ||
.finish_non_exhaustive() | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not derrive_more?
Co-authored-by: Floris Bruynooghe <flub@n0.computer>
Description
Adds a version of ConcurrentDiscovery where the individual discovery services are identified by ids.
That way you can dynamically add them, remove them, and even get a reference.
Breaking Changes
None, this just adds something. In the long term we would probably deprecate and then remove ConcurrentDiscovery however, since the functionality is quite overlapping.
Notes & open questions
The current implementation uses an
Arc<Mutex<HashMap>>
. When using the services in the service trait implementation, we hold the lock while e.g. calling publish. This is OK for a properly implemented discovery service that does not do anything expensive during publish, but you could come up with a convoluted discovery impl that would e.g. try to remove a discovery service during publish, which would cause a deadlock. Also, people might block in publish, meaning that another code path that calls remove would be blocked.Sooo. The safe solution for this is to not hold the lock at all while executing code that can be influenced by the user. To do that there are two approaches:
What do you think?
Change checklist