172 похожих чатов

@Jeudesprits а вы не могли бы объяснить, почему у нас

в swift concurrency есть механизм отмены, который хорошо бы использовать, но при этом чтобы отменить callback based операцию с withCheckedContinuation нужно сделать кучу приседаний?

5 ответов

22 просмотра
Igor- Автор вопроса
Руслан Лутфуллин
Оно?

Если речь про withTaskCancellationHandler, то я вот на такой тред наткнулся и там прям какие-то костыли делают с оберткой для того, чтобы корректно вызвать отмену у объекта выполняемого

Правильно ли я тебя понимаю, что withTaskCancellationHandler в данный момент заставляет использовать некий механизм синхронизации разделяемого состояние, мало того, что это просто лень делать потому что это громоздко, так ещё это сложно сделать правильно? Но по твоей же ссылке кажется и даны ответы. Ну предположим, способ которым можно было бы упростить это дело, сделать этот хендлер асинхронным и его вызов получается синхронным относительно таска у которого вызывается отмена. Окей. Это бы решило проблемы разделяемого состояние, но когда его вызывать внутри таска? Единственная ближайшая такая точка в момент отмены таска, это ближайший suspension point, но переход в этот suspension point будет после того, как потенциальная большая задача в таске завершится или вызовется yield. Это ведь полностью противоречит ожиданиям. Произошла отмена, любой таск в группе это видит и моментально может выполнить задачу, либо выбросит исключение, где его так же моментально можно будет обработать. Но в нашем случае, хендлер не может выполниться моментально, ибо очевидно, что вызов такого хендлера внутри таcка после отмены будет искать suspension point что бы таки вызвать наш хендлер отмены. Здесь правильно было бы сделать более простой механизм защиты разделяемого состояние в таких случаях и сделать его в рамках swift concurrency. А сейчас мы этого не можем сделать. У нас есть актор, но у нас нет механизма отправки сообщений в актор в синхронном контексте. (Это вроде как ожидается, но придётся ждать Swift 6) У нас также в таком случае не гарантируется очередность вызовов в акторе, то есть нет гарантии нужной очередности вызова нашего хендлера. Если бы этого всего можно было избежать, то это бы позволило легче это делать или сделать некий более простой механизм поверх. А пока у нас есть только более-менее простой способ с ManagedBuffer и локом внутри, лучше с os_unfair_lock, либо более быстрый механизм с атомиками. Но всё это выходит за рамки swift concurrency 😐

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта