AM
вопросы должны начинаться с момента "А как её собрать то"
я где-то у них там читал, что под мак они не реализовывают ее
Size: a a a
2020 November 11
AM
хотя, сейчас может что и изменилось..
m
Хм, внезапно. А как корректно тогда реализовать when_all?
Опиши какую семантику ты хочешь от
when_all.VK
Опиши какую семантику ты хочешь от
when_all.Мысль такая, чтобы передать пачку Tasks на выполнение ему и resume корутине, в которой when_all был создан и запущен только по окончанию выполнения всех задач
VK
Т.е. Такая-же как у cppcoro::when_all, только у задач, которые передаются на выполнение- initial_suspend возвращает suspend_newer
m
Мысль такая, чтобы передать пачку Tasks на выполнение ему и resume корутине, в которой when_all был создан и запущен только по окончанию выполнения всех задач
Кажется
makeTaskSequence делает именно это, нет?VK
Кажется
makeTaskSequence делает именно это, нет?Да, верно, но при этом происходит возврат на функцию уровнем выше, которая в свою очередь тоже может сделать makeTaskSequence т.к. не приостановлена
VK
Т.е. проблема, похоже в том, что я пытаюсь стеклесс корутины использовать как стекфул, или нет?
VK
И не могу приостановиться там, где необходимо
m
Т.е. Такая-же как у cppcoro::when_all, только у задач, которые передаются на выполнение- initial_suspend возвращает suspend_newer
> When the returned awaitable is awaited, it will co_await each of the input awaitables on the current thread. Once the first awaitable suspends, the second task will be started, and so on. The operations execute concurrently until they have all run to completion.
Судя по описанию они создают миниатюрный однопоточный рантайм, чтобы конкурентно дожидаться переданных awaitable.
Судя по описанию они создают миниатюрный однопоточный рантайм, чтобы конкурентно дожидаться переданных awaitable.
VK
> When the returned awaitable is awaited, it will co_await each of the input awaitables on the current thread. Once the first awaitable suspends, the second task will be started, and so on. The operations execute concurrently until they have all run to completion.
Судя по описанию они создают миниатюрный однопоточный рантайм, чтобы конкурентно дожидаться переданных awaitable.
Судя по описанию они создают миниатюрный однопоточный рантайм, чтобы конкурентно дожидаться переданных awaitable.
Т.е. я правильно понимаю, что у них никакой магии нет и если у меня есть расшаренный ресурс между Tasks, переданными в when_all к которому нужен уникальный доступ - то синхронизироваться надо отдельно и when_all не причем?
m
Т.е. я правильно понимаю, что у них никакой магии нет и если у меня есть расшаренный ресурс между Tasks, переданными в when_all к которому нужен уникальный доступ - то синхронизироваться надо отдельно и when_all не причем?
Быстро отвечу на этот вопрос.
Нет, так как рантайм однопоточный: it will co_await each of the input awaitables *on the current thread*
Нет, так как рантайм однопоточный: it will co_await each of the input awaitables *on the current thread*
VK
Once the first awaitable suspends, the second task will be started, and so on.
Т.е:
void runAll
->await_suspend Task1->
return to runAll
->restore from Task1
->await_suspend Task2
...
?
Т.е:
void runAll
->await_suspend Task1->
return to runAll
->restore from Task1
->await_suspend Task2
...
?
m
Once the first awaitable suspends, the second task will be started, and so on.
Т.е:
void runAll
->await_suspend Task1->
return to runAll
->restore from Task1
->await_suspend Task2
...
?
Т.е:
void runAll
->await_suspend Task1->
return to runAll
->restore from Task1
->await_suspend Task2
...
?
Нет, это немного по-другому работает. Пока таски не спаунят свои трэды они не могут одновременно исполнятся. По сути однопоточный рантайм работает как-то так:
void run(tasks) {
std::queue queue(tasks);
while (!queue.empty()) {
t = queue.pop_front();
t.resume();
if (!t.done)
queue.push_back(t);
}
}
То есть он просто в цикле исполняет таски. Если таска заблокировалась, кладем ее в конец очереди и берем следующую таску.GN
соррян, черновики)
VK
Нет, это немного по-другому работает. Пока таски не спаунят свои трэды они не могут одновременно исполнятся. По сути однопоточный рантайм работает как-то так:
void run(tasks) {
std::queue queue(tasks);
while (!queue.empty()) {
t = queue.pop_front();
t.resume();
if (!t.done)
queue.push_back(t);
}
}
То есть он просто в цикле исполняет таски. Если таска заблокировалась, кладем ее в конец очереди и берем следующую таску.Хм, интересно. Получается, там реализация отличается от того, что я скидывал
VK
Т.е. тут очередь задач выбирается, пока все задачи не будут готовые(а готовность определяется счетчиком)
m
Хм, интересно. Получается, там реализация отличается от того, что я скидывал
На самом деле я могу ошибаться в том как устроен cppcoro. Я смотрел его кусками и конкретно
when_all не ковырял. Но по описанию и своему опыту я бы сказал что должно быть реализовано примерно так как я описал выше.VK
понял. Буду дальше еще смотреть, переосмыслить when_all попробую. Спасибо!
m
Нет, это немного по-другому работает. Пока таски не спаунят свои трэды они не могут одновременно исполнятся. По сути однопоточный рантайм работает как-то так:
void run(tasks) {
std::queue queue(tasks);
while (!queue.empty()) {
t = queue.pop_front();
t.resume();
if (!t.done)
queue.push_back(t);
}
}
То есть он просто в цикле исполняет таски. Если таска заблокировалась, кладем ее в конец очереди и берем следующую таску.Еще я лукавлю и без реактора (или аналога) таску нормально не заблокировать. В примере выше я просто дергаю не завершившуюся таску в цикле, что плохо работает в плюсовой архитектуре. Но я не готов сейчас рассказывать как построить свой рантайм с корутинами и io от начала до конца.