A
но... я же хочу дождаться завершения отправки всех сообщений. Иначе может случится так, что приложение завершится (в связи с завершением корневой задачи), так и не выполнив до конца этот дисконнект.
Size: a a a
2020 September 10
RP
но... я же хочу дождаться завершения отправки всех сообщений. Иначе может случится так, что приложение завершится (в связи с завершением корневой задачи), так и не выполнив до конца этот дисконнект.
значит жди завершения всех задач рантайма перед завершением приложения
A
значит жди завершения всех задач рантайма перед завершением приложения
Тут уже точно начинает попахивать..
A
Короче, я так понимаю, нормального решения нет.
RP
Коллеги, подскажите, как правильно заимплементить
У меня есть тип-обёртка над сетевым соединением. Внутри сидит асинхронный сокет, а сам тип реализует всякие асинхронные операции, типа собрать и отправить пакет в правильном формате. Также есть асинхронная операция disconnect, которая должна отправить завершающие сообщения в сокет, и только потом его дропнуть. Как мне всё это увязать с RAII и трейтом Drop? Последний вызывается в синхронном контексте, а мне бы хотелось из него выполнить асинхронный disconnect.
Если я кардинально не прав, и RAII не совместим с асинхронщиной - то как быть? Просто выставить disconnect публичным методом и заставлять клиентов его дёргать?
Drop для асинхронных операций завершения.У меня есть тип-обёртка над сетевым соединением. Внутри сидит асинхронный сокет, а сам тип реализует всякие асинхронные операции, типа собрать и отправить пакет в правильном формате. Также есть асинхронная операция disconnect, которая должна отправить завершающие сообщения в сокет, и только потом его дропнуть. Как мне всё это увязать с RAII и трейтом Drop? Последний вызывается в синхронном контексте, а мне бы хотелось из него выполнить асинхронный disconnect.
Если я кардинально не прав, и RAII не совместим с асинхронщиной - то как быть? Просто выставить disconnect публичным методом и заставлять клиентов его дёргать?
A
Спасибо, да, всё сложно. В общем, походу придётся просто выставить disconnect наружу и потребовать через документацию вызывать его в конце работы.
AV
block_on
Дедлок получишь если звёзды сойдутся
AV
Да, RAII не покрывает асинхронную канцелляцию, но она не очень-то и нужна?
AV
Коллеги, подскажите, как правильно заимплементить
У меня есть тип-обёртка над сетевым соединением. Внутри сидит асинхронный сокет, а сам тип реализует всякие асинхронные операции, типа собрать и отправить пакет в правильном формате. Также есть асинхронная операция disconnect, которая должна отправить завершающие сообщения в сокет, и только потом его дропнуть. Как мне всё это увязать с RAII и трейтом Drop? Последний вызывается в синхронном контексте, а мне бы хотелось из него выполнить асинхронный disconnect.
Если я кардинально не прав, и RAII не совместим с асинхронщиной - то как быть? Просто выставить disconnect публичным методом и заставлять клиентов его дёргать?
Drop для асинхронных операций завершения.У меня есть тип-обёртка над сетевым соединением. Внутри сидит асинхронный сокет, а сам тип реализует всякие асинхронные операции, типа собрать и отправить пакет в правильном формате. Также есть асинхронная операция disconnect, которая должна отправить завершающие сообщения в сокет, и только потом его дропнуть. Как мне всё это увязать с RAII и трейтом Drop? Последний вызывается в синхронном контексте, а мне бы хотелось из него выполнить асинхронный disconnect.
Если я кардинально не прав, и RAII не совместим с асинхронщиной - то как быть? Просто выставить disconnect публичным методом и заставлять клиентов его дёргать?
А если у тебя обрыв соединения и отправить дисконнект не получится?
A
Это отдельный вопрос. Если намёк на то, что возникнет ошибка, и её нужно будет куда-то деть - ну, можно просто залоггировать или проигнорить, я полагаю.
AV
Скорее намёк на то что лучше (и проще) закладывать в дизайн нестабильную сеть и использовать жёсткую отмену с дропом соединения
H
А какой метод использовать, чтобы сгруппировать обновления из стрима по какому-то числу (содержащемся в обновлении)? По-моему, мне
groupBy нужен, но я не нашёл его для стримовH
Т.е. ко мне приходит
Stream<Update>, в Update есть id: i32, мне нужно получить стримы, у элементов одного полученного стрима одинаковый idH
https://stackoverflow.com/questions/45684038/splitting-a-futuresstream-into-multiple-streams-based-on-a-property-of-the-str
2017 год и неопубликованный крейт)
2017 год и неопубликованный крейт)
11
Подскажите, я правильно понимаю, что таски в tokio создаются по мере надобности атоматически? Т.е например какая-то футура при ее poll()`инге вернула NotReady, описание со всеми данными продолжает существовать в памяти, а продолжает исполнять другие футуры уже другой таск? (Смотрел исходники, там все хитро-мудро, куча объектов создается которые сами по себе хранят указатели только, и тут же еще работа с потоками как я понял)
ph
>Подскажите, я правильно понимаю, что таски в tokio создаются по мере надобности атоматически?
таски в tokio создаются через tokio::spawn
> Т.е например какая-то футура при ее poll()`инге вернула NotReady, описание со всеми данными продолжает существовать в памяти, а продолжает исполнять другие футуры уже другой таск?
текущий таск кладется в очередь и начинает обрабатываться следующий (при отсутствии готовых заблокируется поток)
таски в tokio создаются через tokio::spawn
> Т.е например какая-то футура при ее poll()`инге вернула NotReady, описание со всеми данными продолжает существовать в памяти, а продолжает исполнять другие футуры уже другой таск?
текущий таск кладется в очередь и начинает обрабатываться следующий (при отсутствии готовых заблокируется поток)
11
>Подскажите, я правильно понимаю, что таски в tokio создаются по мере надобности атоматически?
таски в tokio создаются через tokio::spawn
> Т.е например какая-то футура при ее poll()`инге вернула NotReady, описание со всеми данными продолжает существовать в памяти, а продолжает исполнять другие футуры уже другой таск?
текущий таск кладется в очередь и начинает обрабатываться следующий (при отсутствии готовых заблокируется поток)
таски в tokio создаются через tokio::spawn
> Т.е например какая-то футура при ее poll()`инге вернула NotReady, описание со всеми данными продолжает существовать в памяти, а продолжает исполнять другие футуры уже другой таск?
текущий таск кладется в очередь и начинает обрабатываться следующий (при отсутствии готовых заблокируется поток)
То что они создаются через tokio::spawn я понимаю. Я о том, что на старте приложения я создаю Runtime с необходимыми параметрами и вызываю block_on(), передавая уже весь мой асинхронный код. Получается вручную я тасков не создавал, не спавнил. Т.е будет один таск, что ли?
ph
Да
2020 September 12
11
Вот тут: https://rust-lang.github.io/async-book/04_pinning/01_chapter.html показывают как из асинхронного кода создается state-machine. Насколько я понял, каждый .await в рамках этого блока будет полем конечной структуры, для которой уже будет сделан impl Future for.В связи с чем такой вопрос: если у меня данные условного первого поля структуры никак не зависят от данных второго поля такой структуры, но первое поле исполняется дальше, то исходя из приведенного примера в скинутом линке напрашивается вывод, что второе поле не будет обработано, пока не обработается первое поле. Это так, или я ошибаюсь?
MB
Вот тут: https://rust-lang.github.io/async-book/04_pinning/01_chapter.html показывают как из асинхронного кода создается state-machine. Насколько я понял, каждый .await в рамках этого блока будет полем конечной структуры, для которой уже будет сделан impl Future for.В связи с чем такой вопрос: если у меня данные условного первого поля структуры никак не зависят от данных второго поля такой структуры, но первое поле исполняется дальше, то исходя из приведенного примера в скинутом линке напрашивается вывод, что второе поле не будет обработано, пока не обработается первое поле. Это так, или я ошибаюсь?
Ты волнуешься по поводу излишнего потребления памяти (типа, структура содержит два поля под переменные, хотя в реальности больше одного не нужно)?