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

Support concurrent metadata fetching #3

Open
tdejager opened this issue Oct 26, 2023 · 7 comments
Open

Support concurrent metadata fetching #3

tdejager opened this issue Oct 26, 2023 · 7 comments

Comments

@tdejager
Copy link
Contributor

tdejager commented Oct 26, 2023

This explains it well: pubgrub-rs/pubgrub#138

Also see: https://github.com/orogene/orogene/blob/main/crates/node-maintainer/src/resolver.rs where this is implemented in a tree resolver.

I think we could either make the DependencyProvider async. Or provide a sync and async version or something.

Next to that we should either make resolvo entirely async or use something like a queue to wait on metadata fetching and use this information once it comes available, like I said orogone takes this approach.

@aochagavia
Copy link
Contributor

I've been thinking about async and here is my current take:

  1. Resolvo is heavily CPU intensive, which usually does not work well with async systems. IMO it makes more sense for it to be blocking, at least at the API level.
  2. Internally, we could use async for network requests. I'll think about that :)

@tdejager
Copy link
Contributor Author

Well it's more from an API perspective not an implementation per se. Only the DependencyProvider functions 'get_candidates' and 'get_dependencies' need to be asynchronous.

@tdejager
Copy link
Contributor Author

So those functions can be used in an asynchronous context. Internally we could use a thread pool to dispatch those tasks for example. But otherwise asynchronous code like RIP needs to use the 'block_on' functions to be able to implement the DependencyProvider

@aochagavia
Copy link
Contributor

Ah, now I understand better, thanks!

@Eh2406
Copy link

Eh2406 commented Jan 24, 2024

There is always the risk that the main loop will get stuck so long (doing blocking work) that the asynchronous calls are no longer valid when the library eventually yields. (TCP requires handshakes to be responded to promptly or connections get closed.) Mixing blocking code like the resolution loop and non blocking asynchronous call is tricky.

So far my best advice is to have the asynchronous stuff on one thread and the blocking on a different thread, and have them communicate with channels. But I have not yet build an example. IE figured out if it works in practice.

If you find a good solution, let me know and I will copy it in pubgrub.

@tdejager
Copy link
Contributor Author

Yes your implementation sounds like I had in mind, not sure if we can use the newly stabilized asynchronous trait or if it is too limited still.

Thank you for the comment though :)

@tdejager
Copy link
Contributor Author

Orogone has implemented something similar: https://github.com/orogene/orogene/blob/main/crates/node-maintainer/src/resolver.rs

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 a pull request may close this issue.

3 participants