Pull to refresh

Comments 3

Честно говоря идея контекста WithoutCancel мне так и не ясна.
Если есть функция, которой надо завершится не смотря на контекст, то зачем ей нужен этот контекст?

Если в этой функции нужен контекст для отмены дочерних задач, то тут можно просто от context.Background создать контекст внутри этой функции и раздавать уже его/производные от него.

Что такого дает связь с родительским если от него отмена не придет, а отмена в него по определению не распространяется?

Мне просто казалось контекст тем и хорош, что получив родительский, на его основе можно наплодить сколько нужно своих, зная, что эти дочерние отменятся через cancel/по времени или когда отмена сверху прилетит. И именно такой сценарий чаще всего и нужен ИМХО.

Этот контекст может быть полезен, когда Вы используете контекст, но не хотите, чтобы его отмена повлияла на функцию или метод. Например, иногда необходимо передавать значения из родительского в новый, но нам нельзя его отменять, так как нужно сохранять доступ к значению. Сам контекст же достаточно специфичен в использовании. Ну или например нам нельзя отменять фоновую операцию заполнения кеша. Просто разграничиваем части сервиса, где это требуется. Если отменим базовый контекст, то фоновые процессы все еще будут продолжать работать

Да, пожалуй кейс со значением оправдывает наличие WithoutCancel. Но если контекст без значения то WithoutCancel все таки довольно бессмысленен.

Sign up to leave a comment.

Articles