-
Notifications
You must be signed in to change notification settings - Fork 1
question #1 #2
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
base: master
Are you sure you want to change the base?
question #1 #2
Conversation
@@ -87,10 +87,21 @@ impl GithubExt for Github { | |||
.unwrap_or_default(); | |||
|
|||
let mut result = vec![]; | |||
|
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.
Почему этот код не работает ? как можно сделать так, чтобы это работало ?
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.
Получается я могу только последовательно отправить каждый gql запрос, хотелось бы отправлять их параллельно для разных Variables
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.
Проблема в том, что "таск" запускается позже. Сначала ты готовишь эти таски к запуску. Значит все аргументы для метода post_graphql должны дожить до момента запуска, чтобы быть переданными. self.graphql_url() возвращает String - owned type, но в аргументах к функции ожидается ссылка на эту строку, а строка умирает в конце тела цикла и на неё больше нельзя ссылаться.
Below you can find a dirty solution, which just shows you how you can overcome such issue:
let mut tasks = JoinSet::new();
for variables in variables {
let graphql_url = self.graphql_url();
let client = self.client.clone();
tasks.spawn(async move {
post_graphql::<ContributionsByYear, _>(&client, &graphql_url, variables).await
});
}
let result = tasks.join_all().await;
Но это не самый красивый и оптимальный вариант
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.
@humb1t правильно ли я понимаю, что в этом случае на момент вызова join_all
все таски уже будут выполнены, потому что когда мы добавляем их в tasks
через spawn
, мы вызываем await
на них ? то есть по-сути это всё так же будут последовательно отправленные запросы ?
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.
Почти верно:
Spawns a new asynchronous task, returning a JoinHandle for it.
The provided future will start running in the background immediately when spawn is called, even if you don’t await the returned JoinHandle.
Таски будут запущены, но не факт что успеют выполниться до вызова join_all
.
К сожалению насколько мне известно в Токио нету нормального АПИ для преподготовки набора тасок и потом их запуска "одновременно". Тем не менее, стоит отметить что асинхронное программирование и не преполагает одновременную работу над выполнением этих задач. В первую очередь это неблокирующее выполнение, мы запускаем каждую новую задачу не дожидаясь предыдущей. Если хочется обрабатывать задачи параллельно, можно взять другие рантаймы или сделать многопоточную обработку, однако не уверен что это будет эффективнее.
No description provided.